Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: wawrzon on March 20, 2015, 09:17:29 PM
-
http://www.apollo-core.com/knowledge.php?b=1¬e=2742&z=UH8ZUJ
apparently there is an inquiry for interest.
as well an another option here (vampire2):
http://www.amibay.com/showthread.php?71144-Vampire-600-V2-Amiga-600-FPGA-accelerator-Pre-order
-
I'd love to, but not now :)
-
Count me in!!! I was willing to get ACA1233 but will get this. Is this card compatible with ACA500? 68020 running at speed 500 mhz is quivalent to what speed in x86?
-
afair the cards are meant to be connected to the cpu or cpu socket.
-
afair the cards are meant to be connected to the cpu or cpu socket.
nice!!!
-
I tried to register at apollo forum to say i was interested, but got some error from the email verify link.
I'd like one for a500/2000.
-
I would love to add this to my A2000. Sounds like it sure will beat the daylights out of my 40MHz 030 accelerator, with a total of 21Mb of RAM. Yep - I'm in, if I have to sell half of what I own!
Hey, OldsmobileMike - where are you?
-
Probably work great but no HD controller. Don't have a stand alone one :-(
-
I would love to add this to my A2000. Sounds like it sure will beat the daylights out of my 40MHz 030 accelerator, with a total of 21Mb of RAM. Yep - I'm in, if I have to sell half of what I own!
Hey, OldsmobileMike - where are you?
Tempted! I just got home from work (yes, at 1:30am... it's an early night for me...), gotta think about it! :)
-
Wanted to put forward my interest in one but of course that forum doesn't appear to be accepting new accounts?
Unexpected-Error: We are unable to activate your account.
For further assistance please contact us at info@natami.net
I've sent an email, but would be nice if this was offered through Amibay or elsewhere. My biggest issue is wether to trust handing over $220 NZD + shipping to me some unknown person.
The card does sound good though.
-
Gave up :-/
-
Specs sound decent. Really looking for something that could do full 68040/68060 emulation. I'd take a 100MHz 68060 over a 500MHz 68020, but am happy to see any new development. ;)
I also got the
Unexpected-Error: We are unable to activate your account.
For further assistance please contact us at info@natami.net (info@natami.net)
error. :(
-
Hmm 060, now that would be interesting. Anyway would like to purchase one so emailed info@natami.net.
Still a little hesitant especially with some Amiga hardware projects, notably a certain scan doubler.
-
Still a little hesitant especially with some Amiga hardware projects, notably a certain scan doubler.
I think the only thing Amiga-related that I ever backed, that I got totally screwed over on, was that coupon & shirt deal. What was that, about 2003? 2004? I still want my damned shirt, lol. :lol:
-
Specs sound decent. Really looking for something that could do full 68040/68060 emulation. I'd take a 100MHz 68060 over a 500MHz 68020, but am happy to see any new development. ;)
Is 500 Mhz 68020 slower than 100 Mhz 68060? if they can make a 68020 run at 500 Mhz, why can't they make a 68060 run at 500 Mz instead or even 1 Ghz?
-
I think the only thing Amiga-related that I ever backed, that I got totally screwed over on, was that coupon & shirt deal. What was that, about 2003? 2004? I still want my damned shirt, lol. :lol:
2003? Can't remember, haven't lost money yet touch wood. Love for this card to be real a 500MHz A500? Yes please.
Although building 2MB chip into it would be great then I don't have to worry about fixing my A500 plus.
-
Is 500 Mhz 68020 slower than 100 Mhz 68060?
No, you misunderstand. It is not that you have the choice between a 500 Mhz 68020 or a 100 Mhz 68060. It is neither one nor the other; these numbers should rather give you some feeling about the speed of the FPGA solution, i.e. the FPGA emulates a CPU that has approximately the same user level instruction support as a 68060 or 68020 at the speed grades given above, with a couple of missing instructions handled by a software emulation - in the same way the 68060 had a software emulation layer (in the form of the 68060.library). if they can make a 68020 run at 500 Mhz, why can't they make a 68060 run at 500 Mz instead or even 1 Ghz?
They can neither do one nor another. This is an FPGA emulation of approximately the performance of a 100Mhz 68060 or (equivalently) 500Mhz 68020. Why not faster? Simply because the FPGA cannot go faster, at this time. This is a very small and simple FPGA, with a limited number of cells to program, and with a limited speed grade. There are faster and larger chips, but those are more expensive. Oh, before I forget: There is likely not enough room on the FPGA for a MMU or a FPU, thus integer only, i.e. it is approximately the equivalent of a 68EC060@100Mhz.
-
Is 500 Mhz 68020 slower than 100 Mhz 68060? if they can make a 68020 run at 500 Mhz, why can't they make a 68060 run at 500 Mz instead or even 1 Ghz?
Talking about MHz and processor version numbers isn't very useful other than to say a new core is equivalent to X @ Y MHz. The instruction set will cover the 680x0 CPUs and may be extended further, the core will use modern processor techniques so it isn't an '020 or an '060 it's something a whole lot better.
-
I think the only thing Amiga-related that I ever backed, that I got totally screwed over on, was that coupon & shirt deal. What was that, about 2003? 2004? I still want my damned shirt, lol. :lol:
i dont think this is a pre-payment scheme. at least they were avoiding one before. they are evaluating the interest i guess.
-
Oh, before I forget: There is likely not enough room on the FPGA for a MMU or a FPU, thus integer only, i.e. it is approximately the equivalent of a 68EC060@100Mhz.
are you sure? i thought it was vampire2 limitation, not the gunnars sockit board?
-
Gave up :-/
I have made a comment on the apollo-core forum that there is a problem and people try to sign up and fail
So do not give up :)
-
Hmm 060, now that would be interesting. Anyway would like to purchase one so emailed info@natami.net.
Still a little hesitant especially with some Amiga hardware projects, notably a certain scan doubler.
the card has LAN and a modern video output and it is promised that there will be RTG and a new improved amiga chipset added. At the start it is a accellerator with 128 MB RAM.
-
are you sure? i thought it was vampire2 limitation, not the gunnars sockit board?
The limitation is the number of available cells in the vampire or vampire 2. It's an FPGA, so it does whatever you program it to do. If you program it to have a MMU, it would - just that the current FPGAs are just too small to allow one. Besides, to my very knowledge, Gunnar does even have code for a MMU.
-
yes, even though i thought that bga package igor is using now woulkd be bigger than the previous one. but actually we are reffering here to that sandwitch socit board proposed by gunnar, arent we? and i thought that would be begi enough for what he considers a full core.
-
yes, even though i though that bga package igor is using now woulkd be bigger than the previous one. but actually we are reffering here to that sandwitch socit board proposed by gunnar, arent we? and i thought that would be begi enough for what he considers a full core.
the thread you are referring to is for the bigger FPGA
-
Seems there is some confusion due to different option being developed in parallel and announced at the same time. Its important that ecerybody checks his facts exactly before ordering.
-
Seems there is some confusion due to different option being developed in parallel and announced at the same time. Its important that ecerybody checks his facts exactly before ordering.
I'm talking about the vampire 2. That's "a bit bigger", but not much. Doubtful whether that's enough headroom for any extra. If you pick a completely different FPGA, sure, but there's no MMU design Gunnar has made. There are larger caches, superscalar cores and so on, but none that would feature a MMU for example.
-
The development boards referred to in this thread are combo cards like this pair (http://s14.postimg.org/tx62w9qtt/apollo_Phoenix2.jpg) for the A500/A1000/A2000. A pair including an adapter board with a PLCC socket for the A600 is proposed.
-
so, thomas, in your opinion is gunnars design sufficient for a full blown core with fpu and with some sort of mmu eventually?
-
There is a version of the FPGA board that is 4 times bigger, so space for logic/features will not be an issue for those prepared to pay for it.
-
so, thomas, in your opinion is gunnars design sufficient for a full blown core with fpu and with some sort of mmu eventually?
Well, I'm not an FPGA expert, so it's hard to judge. But from the size of the FPGA, it should be sufficient for these functions. However, this still means that somebody has to implement them.
-
the card has LAN and a modern video output and it is promised that there will be RTG and a new improved amiga chipset added. At the start it is a accellerator with 128 MB RAM.
Is the new improved Amiga chipset something like Super AGA or something better than OCS/ECS/AGA but along the line of new improved custom chipset? Will it be backward compatible with OCS/ECS/AGA?
If we make games on the new improved custom chipset does that mean it will not run on Amiga CD 32/A500/1200/etc that do not have this chipset installed in their system?
Thank you OlafS3 for answering below. I will have the money ready on 26th and wish to preorder it. I will buy this card over ACA1233 (originally was intending on buying the ACA1233). How do I go about doing it?
-
Is the new improved Amiga chipset something like Super AGA or something better than OCS/ECS/AGA but along the line of new improved custom chipset? Will it be backward compatible with OCS/ECS/AGA?
If we make games on the new improved custom chipset does that mean it will not run on Amiga CD 32/A500/1200/etc that do not have this chipset installed in their system?
As I understand it the chipset is planned to be backward compatible and also with more advanced features. But I am not involved there so it is better gunnar answers that.
-
I do hope people realize these are developer boards, not really meant as end user products yet.
-
the card has LAN and a modern video output and it is promised that there will be RTG and a new improved amiga chipset added. At the start it is a accellerator with 128 MB RAM.
Which from what I was reading can be enabled over time with firmware updates as the hardware is all there just not enabled?
Would like to be part of this if I can as it is about time a good accelerator appeared especially with the tech that is available now.
The price is spot on too, anyway will hurry up and wait. Hopefully they will sort out their forum or allow interest to be taken here.
-
I do hope people realize these are developer boards, not really meant as end user products yet.
Well, I like to assume that people have a reading comprehension above 3rd grade level, but probably best not to assume. ;)
The purpose of the production run is to enable more developers to write drivers - and to enable testers to better test for full 68020 compatiblity. This is NOT a sales run for normal customers.
The cards will be provided with programming cable.
The developers are expected to update the card regularly.
The cards will be produced for the developers/testers for participation fee on the production run. I expect this cost to be in the range of about 150 %&$#?@!%&$#?@!%&$#?@!8364; total.
So, they're for people willing to test the hardware, as well as developers. I think several of us would fall squarely into that "tester" category. ;)
-
Which from what I was reading can be enabled over time with firmware updates as the hardware is all there just not enabled?
Would like to be part of this if I can as it is about time a good accelerator appeared especially with the tech that is available now.
The price is spot on too, anyway will hurry up and wait. Hopefully they will sort out their forum or allow interest to be taken here.
it will be updated over time. As someone already mentioned it is about developer boards to have more people testing and developing for it (like drivers). There will be updates over time. At the start it is accellerator with 128 MB RAM, other features will be added later.
I have left a comment there regarding registration problems and a link to this thread
-
So, they're for people willing to test the hardware, as well as developers. I think several of us would fall squarely into that "tester" category. ;)
As long as you don't have too high expectations and are able to produce feedback that is usefull, sure. I see it mentioned here that RTG is promised - nothing is promised, everything is hopefully coming.
-
Unexpected-Error: We are unable to activate your account.
For further assistance please contact us at info@natami.net
Still not working.
@OlafS3 Thanks for your help, hopefully we'll here some good news.
@kolla No expectations other than it's a fast card with 128MB RAM at this stage.
-
I'm talking about the vampire 2. That's "a bit bigger", but not much. Doubtful whether that's enough headroom for any extra. If you pick a completely different FPGA, sure, but there's no MMU design Gunnar has made. There are larger caches, superscalar cores and so on, but none that would feature a MMU for example.
Hello everbody.
First of all : ALL FORUM ACCOUNT ARE NOW ACTIVATED.
So if you did sign up, you can use the account now.
2nd - if you ever have need to support - please visit the IRC channel.
There is always someone around..
3rd Lets quickly compare the cards to get a better overview.
The VAMPIRE-600-2 is product for the A600
It has a faster and bigger FPGA than the VAMPIRE-600-1.
Its a pure CPU Card. It will be pure Integer.
The maximum expected performance that we have for with
this card is something in the ballpark of a 100 MHz 68060.
But no guarantee for this yet.
The C5 Apollo Phoenix Card is a develop card for a program in the Apollo website.
If has a much bigger FPGA. A lot more performane is here expected.
The C5 card has room for FPU.
But will be first deliveared with an Integer core.
The C5 is NOT available for end users - its a pure tester and developer program we want to do.
-
i must say im very tempted to find somewhere an a600 again, register at the apollo forum and get a test run board, even theough i swore myself tot to buy any more amiga rubbish (;)) any soon, still im not sure if i can contribute much to testing, let alone the development. on the other hand, he more testers, the more current.
gunnar, when is the deadline one has to made up their mind?
-
Hello everbody.
The C5 is NOT available for end users - its a pure tester and developer program we want to do.
So, to be a tester is there anyone special you are looking for or can anyone become a tester. ?
-
Thanks biggun, managed to logon today. Hopefully I get to be involved.
-
errrm, guys, even being op in this thread, silly question, how have you managed to register?
im seriously starting to think about getting another a600;)
-
errrm, guys, even being op in this thread, silly question, how have you managed to register?
im seriously starting to think about getting another a600;)
A500 or A600 :)
If the register not works Gunnar has another homepage and the email there should work. I do not know if the email on the register page works now or not. It seems there was a problem. If you have a problem I could also leave a message on the apollo core forum.
-
a500 is too bulky. i have a sentiment for the 600 for its compact form factor and because it was the firsta amiga i owned;). but i would have to get ks3.1 for it first as i understand.
i was a member on natami forum, they could take my details from there or from you.
-
a500 is too bulky. i have a sentiment for the 600 for its compact form factor and because it was the firsta amiga i owned;). but i would have to get ks3.1 for it first as i understand.
i was a member on natami forum, they could take my details from there or from you.
I love A500 because it was the very first Amiga computer I was ever introduced and used in my life. My jaws dropped at the quality of the graphics in the game and how I fell in love with it. To me Amiga 500 is going to be my own all usage Amiga computer usage and I love the keyboard case :)
-
im not questioning nor want to discuss anybody elses preference. its important for me to have most compact and mobile unit if possible, because i move around, and it was the first time like that. thats all
-
im not questioning nor want to discuss anybody elses preference. its important for me to have most compact and mobile unit if possible, because i move around, and it was the first time like that. thats all
I understand and I agree. :) Compact is good, especially when space is an issue.
-
a500 is too bulky. i have a sentiment for the 600 for its compact form factor and because it was the firsta amiga i owned;). but i would have to get ks3.1 for it first as i understand.
i was a member on natami forum, they could take my details from there or from you.
I do not know if Gunnar has access to the Natami forum (he was not administrator there) and passwords are normally hidden. Best is to try to registrate and if not works inform me and I can post it on apollo forum.
A600 is my favorite too because it is small and I want to show it at amiga meeting(s) :)
-
I prefer A3000T, A1200T and A4000T because a real Man(tm) uses a computer that requires a Fork Lift to get the thing in/out of the car at the Amiga Meetings. :D
-
I think the only thing Amiga-related that I ever backed, that I got totally screwed over on, was that coupon & shirt deal. What was that, about 2003? 2004? I still want my damned shirt, lol. :lol:
HA! I forgot all about that! I want my coupon and shirt now!
-
Comparing sizes, first group of ordered parts are here.
http://majsta.com/modules.php?name=News&file=article&sid=94&mode=&order=0&thold=0
-
majsta nice, looking forward to more photos :) love watching hardware projects come together, might have to buy a 600...
-
So, to be a tester is there anyone special you are looking for or can anyone become a tester. ?
Testers do _NOT_ need to know anything about VHDL, chip design, or FPGA programming.
Ideally testers should be keen on trying out several games , programs or demos.
Phoenix comes to you with something buildin similar to an action replay.
If a demo fails - a tester should be willing to use the action replay and "grap" the failing code part.
We can show you how to do this.
I great help would be if some testers have some 68K ASM knowledge or are interested in learning this.
Testers should be willing to make screenshots / take pictures or movies e.g. showing ADoom with 50 FPS. :-)
Testers should not be afraid to own the fastest Amiga.
-
@Biggin Sounds good to me, gives me an excuse to update my YouTube account :)
-
Testers do _NOT_ need to know anything about VHDL, chip design, or FPGA programming.
Ideally testers should be keen on trying out several games , programs or demos.
Phoenix comes to you with something buildin similar to an action replay.
If a demo fails - a tester should be willing to use the action replay and "grap" the failing code part.
We can show you how to do this.
I great help would be if some testers have some 68K ASM knowledge or are interested in learning this.
Testers should be willing to make screenshots / take pictures or movies e.g. showing ADoom with 50 FPS. :-)
Testers should not be afraid to own the fastest Amiga.
Let me know how I can take part.
I own a Amiga500 rev 6a, amiga1200 1.4.d, and a amiga600.
Btw: I am registered on both apollo-core.com & Natami.net
-
Let me know how I can take part.
I own a Amiga500 rev 6a, amiga1200 1.4.d, and a amiga600.
Btw: I am registered on both apollo-core.com & Natami.net
there is this thread on apollo core forum:
http://www.apollo-core.com/knowledge.php?b=7
just write there that you are interested and if you prefer A500 or A600
-
Whats up with you guys, lets get some more people interested. The card sounds like a step in the right direction.
Who doesn't want a 500Mhz A500? Kind of fitting when you think about it A500...500MHz...
I don't like the comment from Michal Warzecha saying not many posts for now, I don't want to see this fold.
Even if they could do a small developer/tester run through Kickstarter?
-
Whats up with you guys, lets get some more people interested. The card sounds like a step in the right direction.
Who doesn't want a 500Mhz A500? Kind of fitting when you think about it A500...500MHz...
I don't like the comment from Michal Warzecha saying not many posts for now, I don't want to see this fold.
Even if they could do a small developer/tester run through Kickstarter?
I have already put a request in the list. How many have being interested and how many are missing?
-
I have already put a request in the list. How many have being interested and how many are missing?
Not sure but the more interest the better I would say :-)
-
I'm interested in the A500 version, although I will miss my VXL*30. :)
-
I have an VXL*30, could never find the RAM module for it so it's now sitting in a box.
-
Who doesn't want a 500Mhz A500? Kind of fitting when you think about it A500...500MHz...
I am sorry but these cards are not 500 Mhz.
-
I am sorry but these cards are not 500 Mhz.
why so negative. ?
this is the only development happening for the amiga right now.
-
I am sorry but these cards are not 500 Mhz.
It does not matter whether these cards are clocked with 200 or 500 or 800 ...
As long as they are as FAST as an 68030 @ 500 MHz people will be happy
-
It does not matter whether these cards are clocked with 200 or 500 or 800 ...
As long as they are as FAST as an 68030 @ 500 MHz people will be happy
Yup. :hammer: Wait, does that mean we get a cpu fan too!!!?? :) :)
-
I don't think the Amiga is cursed it's just the negative vibes that scare project developers away :-P
It can provide a 500MHz experience and that is all that matters. Now where do I send my money, and can we have some photo teasers?? ;-)
-
No, it is the OS that scares developers away, too much common infrastructure is lacking, too few standards are present.
-
I would be interested in the A500 Version as well. The Forum seems to not be activating users again.
-
Jim Drew should get a board and make sure Macintosh emulation will work. In time maybe he could implement a Macintosh chipset on FPGA too, and have it running all natively.
-
Jim Drew should get a board and make sure Macintosh emulation will work. In time maybe he could implement a Macintosh chipset on FPGA too, and have it running all natively.
Who wants macintosh/apple fpga!, we want a amiga clone/ with improved hardware.
guess you know what happens to anyone trying to make a apple clone u know what happens to those companies!....
-
No, it is the OS that scares developers away, too much common infrastructure is lacking, too few standards are present.
You must have missed my :-P Smilie, oh sorry emoticon as they are called now. ;-)
-
Who wants macintosh/apple fpga!, we want a amiga clone/ with improved hardware.
It's really about ensuring CPU compatibility, since MacOS is different and alien, but can be easily run ontop of AmigaOS, it is a nice corner case to test out.
guess you know what happens to anyone trying to make a apple clone u know what happens to those companies!....
The ghost of Steve Jobs comes visiting? :)
-
You must have missed my :-P Smilie, oh sorry emoticon as they are called now. ;-)
I believe "emoji" is the current term, haha ;)
-
@biggun
Can i pay for it now to preserve a seat. Even if this card just end up 500 mhz accelerator it is good enough for me. Everything else is a bonous
-
I am sorry but these cards are not 500 Mhz.
why so negative. ?
Since when is stating facts and the truth negative?
Jim Drew should get a board and make sure Macintosh emulation will work. In time maybe he could implement a Macintosh chipset on FPGA too, and have it running all natively.
MacOS emulation on Phoenix would require major patchwork with the last I heard of Gunnar's ISA (no documentation or ISA encoding maps are available so no one knows for sure). Some 68020 ISA instructions which are illegal on the Amiga but necessary in MacOS like CAS and CAS2 are not implemented and even the encoding may be partially gone (reused). I was initially in favor of the change which improves consistency, simplifies decoding and is slightly better at code density but decided it was not worthwhile after doing code analysis and finding another way to gain most of the code density (the code density gain would be <1% for most programs if assemblers followed an ISA which was documented intelligently). Other problems include lack of a 68k compatible MMU (for a half way modern MacOS environment anyway) and dropping of packed BCD decimal fp support in the FPU (the MacOS uses this according to Jim Drew). The latter could probably be worked around and was likely never used by Amiga programs (I've never seen it or heard of it).
-
Well, as I mentioned, it would be interesting to see Shapeshifter or other Mac emulation on Amiga with a Phoenix core, Shapeshifter does not require MMU I believe. Anyways, what are the odds that other software, such as games and demos that bypass the OS with their coding, use features not found on Phoenix?
-
Well, as I mentioned, it would be interesting to see Shapeshifter or other Mac emulation on Amiga with a Phoenix core, Shapeshifter does not require MMU I believe. Anyways, what are the odds that other software, such as games and demos that bypass the OS with their coding, use features not found on Phoenix?
You know what it means with such a speed. VICE emulator, DOSBox and other emulation should run very smoothly now in all Amiga models and on top of it, even Exult should run very fast.
-
Should yes, but it remains to see if they will run at all. Currently even OS3.9 doesn't work well, but that should be fixed quickly one can hope. The thing with Macintosh emulators is that the CPU is not emulated in those.
-
Should yes, but it remains to see if they will run at all. Currently even OS3.9 doesn't work well, but that should be fixed quickly one can hope. The thing with Macintosh emulators is that the CPU is not emulated in those.
What is wrong with OS 3.9? You said even the actual OS 3.9 does not work well, why?
Side note: In the very very very distance between Jupiter and Earth future, if the SAGA does become reality then all Amiga specs will be 100% the same. It will be who ever choose an Amiga model it will be for the sole reason of the flavor he likes and favorite style more than anything else. AGAIN IF THIS VERY between Earth and Jupiter distance future does become reality then I am content with my favorite flavored A500. Others will be A600, while others be will be A1200 and others will be A4000.
THE VERY CONCEPT excites me!
-
Be interesting to know what the issue is with AmigaOS3.9. Even a 030@40MHz has no issues running it, have it setup nicely on my A500 at the moment using the IndiECS as an RTG card.
Which works really well apart from the occasional artifact/pixels but then the IndiECS wasn't really meant to be used as an RTG card ;-)
-
FUSION does not need a MMU, but a MacII and later emulation requires complete 68020 emulation, which means all extended addressing modes, CAS, CAS2, etc.
-
Be interesting to know what the issue is with AmigaOS3.9. Even a 030@40MHz has no issues running it, have it setup nicely on my A500 at the moment using the IndiECS as an RTG card.
Which works really well apart from the occasional artifact/pixels but then the IndiECS wasn't really meant to be used as an RTG card ;-)
By the way, when I had the indivision ECS scandoubler on my A500 before I lost it...I did not like it. I mean I like the idea that I can hook my A500 in a monitor anytime...I just did not like the quality (ignoring the fact the board was defective and the image came gibberish).....it felt worse than WinUAE. TOOO...pixilated, WinUAEish...I do not know. But ones I hooked my A500 back in TV it felt the good old days again. I rather treat my A500 the same way I treat Commodore 64...composite or rf and TV.
Now if you are telling me to go A4000T/D using for example AmiKit as an OS...hooking it on a monitor makes all sense..and VGA is a necessity and not a choice.
-
Well, as I mentioned, it would be interesting to see Shapeshifter or other Mac emulation on Amiga with a Phoenix core, Shapeshifter does not require MMU I believe. Anyways, what are the odds that other software, such as games and demos that bypass the OS with their coding, use features not found on Phoenix?
Programs which do not use the MMU or FPU should not need much supervisor use. A little bit of code can be very problematic though. CPU detection code, interrupt handling, supervisor stack code, etc. can cause problems. I don't know how much work Gunnar has done to support supervisor emulation.
Be interesting to know what the issue is with AmigaOS3.9. Even a 030@40MHz has no issues running it, have it setup nicely on my A500 at the moment using the IndiECS as an RTG card.
I don't think the Phoenix AmigaOS 3.9 problem is with emulation but rather initialization.
-
Some 68020 ISA instructions which are illegal on the Amiga but necessary in MacOS like CAS and CAS2 are not implemented and even the encoding may be partially gone (reused).
It's pretty pointless trying to consider any other platforms as it's obvious that the focus is on a solution that relies on AmigaOS with new software that makes use of any potential new mmu.
If you want to be able to run anything interesting like Next Step then you need to change mind set and create something that is compatible with the real chips rather than trying to make small percentage increases by discarding compatibility.
There are platforms that use illegal instructions etc. If the code was open source with multiple build options then it would be workable, but as a closed source solution it's like being taken on a mystery tour that the destination isn't quite where anybody but the driver wants to go. The people on the bus were sold at the beginning of the journey but then make excuses that hindsight is a wonderful thing.
-
Since when is stating facts and the truth negative?
Truth is good.
Can you start posting the truth instead spreading false rumours?.
MacOS emulation on Phoenix would require major patchwork with the last I heard of Gunnar's ISA (no documentation or ISA encoding maps are available so no one knows for sure). Some 68020 ISA instructions which are illegal on the Amiga but necessary in MacOS like CAS and CAS2 are not implemented
What you say is not true.
CAS and CAS2 are supported.
Matt, you lack overview about Phoenix.
I've noticed that you very often post wrong and untrue stuff.
Posting wrong info does help no one.
-
So Mac emulators are no go, I wonder what else of proprietary software that will end up as "no go" because the Phoenix CPU core is (will be) too incompatible and needs dedicated support. I would love to participate with my A600, but wont be able until fall. What is the time frame for these developer boards anyways?
-
Matt, you lack overview about Phoenix.
I've noticed that you very often post wrong and untrue stuff.
Posting wrong info does help no one.
I believe everybody is confused now. The small phoenix core for the Vampire does not include CAS2; instead, it is emulated in software, which is not a loss. However, the emulation cannot run a "locked bus access" since that's simply not supported by Phoenix. Then again, this is not a loss either since it is a single-processor system, and there is no sense in locked accesses in first place. Leave alone that Amiga hardware would even support locked transfers, which it does not. So, conclusions: CAS/CAS2/TAS are pretty useless instructions for Amiga, and not even supported by the native Amiga hardware. Yet, apparently, some Mac software depends on them. The small Phoenix core does not implement CAS2 and CMP2, though the software library does. It does not use locked transfers, simply because there are no locked transfers on Phoenix, which is - however - not critical since there is no second CPU.
-
So Mac emulators are no go, I wonder what else of proprietary software that will end up as "no go" because the Phoenix CPU core is (will be) too incompatible and needs dedicated support. I would love to participate with my A600, but wont be able until fall. What is the time frame for these developer boards anyways?
No, why? For the same reasoning, one could never had run shapeshifter on a 68060 because it has unsupported instructions that require emulation. No difference. Once the software emulation layer is loaded, there is no problem.
-
And this emulation is done in a library akin to 68040.library? Or by PhoenixInit that also loads FastRAM? What's the deal with OS3.9 and PhoenixInit, considering that initial boot of 3.9 is in fact a 3.1 before SetPatch loads all 3.9 stuff and resets. Does PhoenixInit have to be run on every single warm boot? That is kinda inconvenient for games that boot off their own media.
-
And this emulation is done in a library akin to 68040.library? Or by PhoenixInit that also loads FastRAM?
I don't know how Gunnar currently handles that. Ideally, it should be a library. Currently, I deliver a run-alone binary I deliver that installs everything. There is no support for the Phoenix core in SetPatch, so you have to use an additional command to load the support functions anyhow. What's the deal with OS3.9 and PhoenixInit, considering that initial boot of 3.9 is in fact a 3.1 before SetPatch loads all 3.9 stuff and resets.
I don't know - what do you mean by "deal"? Somehow, the stuff must be loaded, right? Does PhoenixInit have to be run on every single warm boot? That is kinda inconvenient for games that boot off their own media.
Does the 68040.library have to be loaded on every warm start? Yes, of course. Does the absense of the 68040 library break some games? Probably, I never tried. It is more likely that bad software does not run on the 68040 in first place, especially software that bypasses the Os. Did that stop people from using the 68040 or 68060?
In a sense, you cannot have everything. P96 support requires 68020 support. Some games break on a 68020. Fast execution requires higher clock rates. Some games break on faster processors. At some point, you probably just have to say, ok, I'll boot this game with the plain old 68000 in the system. If software is so badly written that it cannot run with SetPatch kicking in, or so bad that it does not run on anything but raw 68000 speed at 7MHz... well - I'm just saying "bad luck", that's not the right hardware for this game.
-
I don't know how Gunnar currently handles that. Ideally, it should be a library. Currently, I deliver a run-alone binary I deliver that installs everything. There is no support for the Phoenix core in SetPatch, so you have to use an additional command to load the support functions anyhow. I don't know - what do you mean by "deal"? Somehow, the stuff must be loaded, right?
Does the 68040.library have to be loaded on every warm start? Yes, of course. Does the absense of the 68040 library break some games? Probably, I never tried. It is more likely that bad software does not run on the 68040 in first place, especially software that bypasses the Os. Did that stop people from using the 68040 or 68060?
In a sense, you cannot have everything. P96 support requires 68020 support. Some games break on a 68020. Fast execution requires higher clock rates. Some games break on faster processors. At some point, you probably just have to say, ok, I'll boot this game with the plain old 68000 in the system. If software is so badly written that it cannot run with SetPatch kicking in, or so bad that it does not run on anything but raw 68000 speed at 7MHz... well - I'm just saying "bad luck", that's not the right hardware for this game.
One word: Whdload.
-
One word: Whdload.
Well, even that cannot clock down a 68060 to 7Mhz or change the exception stack frame for a 68040. It can at best perform a live patch on broken software. How good or bad that works depends of course on the software and WHDLoad. One way or another: If you need absolute compatibility to a 1MB 68000@7Mhz on an Amiga 500, your best bet is to get an unexpanded Amiga 500....
-
Well, even that cannot clock down a 68060 to 7Mhz or change the exception stack frame for a 68040. It can at best perform a live patch on broken software. How good or bad that works depends of course on the software and WHDLoad. One way or another: If you need absolute compatibility to a 1MB 68000@7Mhz on an Amiga 500, your best bet is to get an unexpanded Amiga 500....
This is why the vampire 500 is awesome. Anytime you can disabled and get that 100% compatibility since you run it on an unexpected A500 anyways
-
Well, it should be possible to let regular SetPatch do it the same way it does 68060.library, via a dummy 68040.library, but I suppose it then would had to act like a 68040 to trigger SetPatch to load it. Most convenient of all, for users, would be if phoenix core could be compatible enough to not need patching of the OS, isn't that the greatness of FPGA? Also, that the FastRAM is not autoconf is rather inconvenient.
I am curious how it will play out.
-
Well, it should be possible to let regular SetPatch do it the same way it does 68060.library, via a dummy 68040.library, but I suppose it then would had to act like a 68040 to trigger SetPatch to load it. Most convenient of all, for users, would be if phoenix core could be compatible enough to not need patching of the OS, isn't that the greatness of FPGA? Also, that the FastRAM is not autoconf is rather inconvenient.
I am curious how it will play out.
Only way to figure it out if BigGun start distributing tomorrow the card for people who said they are interested! Then we can start playing :laugh1: with card and say how the entire thing works out.
Right now I am exercising extreme control and patience of not buying ACA1233 but that means my A500 is crippled for what I need to do with it. I do hope it comes out soon.
-
Well, it should be possible to let regular SetPatch do it the same way it does 68060.library, via a dummy 68040.library, but I suppose it then would had to act like a 68040 to trigger SetPatch to load it.
Actually, that's a bad idea since the Phoenix is not an 68040, and even if it would emulate one, the 68040.library should be reserved for the original 68040. A well-designed system should boot no matter what the CPU is, and SetPatch should pick up the right library in first place - there should be no need for a dummy. One way or another, this could be solved by making the code an autoconf module and bootstrap it this way. Most convenient of all, for users, would be if phoenix core could be compatible enough to not need patching of the OS, isn't that the greatness of FPGA? Also, that the FastRAM is not autoconf is rather inconvenient.
Actually, it does not require patching the Os. The support code is only there to provide emulation code for the instructions it does not support. The emulation code does not patch the Os - what for? The reason why there are unsupported instructions in the Phoenix is simply because the FPGA is too small to include them. Regularly, you don't need them anyhow, it only affects a minority of programs in first place. Other than that, the Vampire can be bought right away, though unfortunately it is not "easy enough" for the average user to get it, install the core and get it running, i.e. it is not "a product". For that, the core would have to be pre-installed, and it should be available in larger quantities. It is currently too much of a "hobby project" to make it feasible for the average user.
-
Truth is good.
Can you start posting the truth instead spreading false rumours?
What you say is not true.
CAS and CAS2 are supported.
Matt, you lack overview about Phoenix.
I've noticed that you very often post wrong and untrue stuff.
Posting wrong info does help no one.
What is the truth? Can you tell us when you change your mind again and update your documentation (the only documentation I find is N68050 encoding maps)? The truth can change especially where you control it. The last truth (or lie from your posts) was that you were using OPI.L #.W, which would partially overwrite encodings of some other instructions like CAS, CAS2 and CMP2.
http://www.apollo-core.com/knowledge.php?b=4¬e=2732
Did you finally listen to ThoR after arrogantly running Meynaf and me off for suggesting the same thing? You finally caved to adding all the 68020 addressing modes after Meynaf and I told you having them would provide best compatibility and keep some heavy using programs from crawling due to traps. I would like to support your project but I won't put up with your arrogance and abuse.
-
That falls under "patching" in my eyes, but details. I agree that putting everything in a autoconf module would be best, so everything is available from coldboot. Some flash memory to also hold kickstart image would be great. Btw, how is the "SYS:Expansion" drawer used, if it all? I never saw it used for anything.
-
That falls under "patching" in my eyes
if adding library for few unsupported instructions is patching the os, then 040/060 require this as well. apparently you cant just "patch" the os that way to make it work with coldfire for example, which speaks for apollo core compatibility.
this is one thing. another is, that the more instruction a cpu doesnt provide without a library support, the less it is compatible for "nodos" software, that not accept being run from the operating system. of course it is usually only old games, that do not require acceleration in first place, its nice though staying compatible even with these as far as possible.
-
What is the truth? Can you tell us when you change your mind again and update your documentation (the only documentation I find is N68050 encoding maps)? The truth can change especially where you control it. The last truth (or lie from your posts) was that you were using OPI.L #.L, which would partially overwrite encodings of some other instructions like CAS, CAS2 and CMP2.
http://www.apollo-core.com/knowledge.php?b=4¬e=2732
Did you finally listen to ThoR after arrogantly running Meynaf and me off for suggesting the same thing? You finally caved to adding all the 68020 addressing modes after Meynaf and I told you having them would provide best compatibility and keep some heavy using programs from crawling due to traps. I would like to support your project but I won't put up with your arrogance and abuse.
even if discussion is heated, if it leads to a positive result and reconsideration in the end, i find it a rather positive sign. i am accustomed to completely different behaviour in this scene.
-
By the way, when I had the indivision ECS scandoubler on my A500 before I lost it...I did not like it. I mean I like the idea that I can hook my A500 in a monitor anytime...I just did not like the quality (ignoring the fact the board was defective and the image came gibberish).....it felt worse than WinUAE. TOOO...pixilated, WinUAEish...I do not know. But ones I hooked my A500 back in TV it felt the good old days again. I rather treat my A500 the same way I treat Commodore 64...composite or rf and TV.
This argument over composite/RF is better than a 100% working Indi is silly. Colour bleeding and blurred pixels vs picture perfect crisp screen.
I don't think it's a quality thing, more misplaced nostalgia. Either that or a faulty Indi.
Who doesn't want an A500 with 800x600@256 colour workbench? Switching is also seamless between playing an WHDLoad game and coming back to workbench unlike my A1200T where I have a switch to do that.
Also enjoying playing Doom 640x480 with 256 colours :-)
Playing old school games is also amazing, no tearing and look great on my 27" monitor. Colours seem to pop more too, actually some games I notice more detail than back in the day.
I'm like a kid in a candy shop everytime I fire up igame when the full colour thumb nails, 1000 games down 1900+ to go through.
-
Can't wait to see what happens if I do get the opportunity to test the faster accelerator, I believe that with the extra speed I could push workbench further :-)
Fingers crossed :-) :-) :-)
-
That falls under "patching" in my eyes, but details.
Well, a "patch" is - as the regular meaning of the word in the English language suggests - a piece of fabric (or code) placed on top of a hole on a piece of sheet (or Operating System, for that matter). So my meaning of the word "patch" is that you replace some instruction or function in a program or the Os. That does not happen here, i.e. the Os remains unaffected. Except for installation, the Phoenix support code does not even require the Os. Anyhow, let's not be hairsplitting here. Btw, how is the "SYS:Expansion" drawer used, if it all? I never saw it used for anything.
It's used by "BindDrivers". This command scans the autoconf-database, i.e. "expansion.library", checks for unconfigured expansions, and if so, gets its vendor and product ID. It then scans for an icon in SYS:Expansion whose product and vendor ID matches, and loads the corresponding binary. In other words, SYS:Expansion contains firmware for autoconf hardware that does not contain driver code. Typical examples are serial or parallel port expansions. It does not make sense to make their hardware more complicated than necessary and include an EPROM there because you do not want to boot from them in first place, so the firmware sits on disk in SYS:Expansion.
-
Well, even that cannot clock down a 68060 to 7Mhz or change the exception stack frame for a 68040. It can at best perform a live patch on broken software. How good or bad that works depends of course on the software and WHDLoad. One way or another: If you need absolute compatibility to a 1MB 68000@7Mhz on an Amiga 500, your best bet is to get an unexpanded Amiga 500....
WHDLoad is all I use to run older games/software. Works fine with the 060@80MHz on the A1200 and the 030@40MHz on the A500.
Worse comes to worse I can always use rekick or something similar via the Gotek and boot a really stubborn game or one I can't find under WHDLoad.
The only game I'm having to do that for at the moment is IK+ as its the only way to get sound effects to work on the bomb/ball levels. Other than that I'm in Workbench all the time using WHDLoad/igame.
I don't see the issue here, it's going to be fine. Can't wait to prove the people wrong and post photos videos ;-)
-
apparently you cant just "patch" the os that way to make it work with coldfire for example, which speaks for apollo core compatibility.
Well, actually, one could. Except that the result would be unbearably slow. The problem with the coldfires is that they only support 32-bit math, so every word-based or byte-based arithmetic instruction would require an emulator trap. And there are plenty of them, it's really a pretty common type of instruction on the Amiga. this is one thing. another is, that the more instruction a cpu doesnt provide without a library support, the less it is compatible for "nodos" software, that not accept being run from the operating system. of course it is usually only old games, that do not require acceleration in first place, its nice though staying compatible even with these as far as possible.
Well, the (small) Phoenix core for the Vampire (and we're only talking about this core at the moment) does not support only instructions that are barely used anyhow. First, some 68020+ instructions like some 64-bit math (only 68020 anyhow), bitfield instructions (hard to do in pure hardware, slow anyhow, and 68020 and above only), MOVEP (rarely used, if ever, but available on 68000), BCD-arithmetics (ABCD,NBCD,SBCD - 68000, but rarely ever used) and the CAS2/CMP2 instructions, which are also rarely ever used, and 68020 and above only.
Parts of the set are already unsupported on the 68060 (parts of 64 bit math,CAS2,CMP2), some parts are new, but again usually not used (BCD arithmetic, MOVEP). Only bitfields are *sometimes* used, but they are really hard to do right. Especially, they need to read up to five bytes for a single instruction, and may not read or touch any byte outside of the requested range (to avoid side effects on hardware registers). Their emulation looks surprisingly complicated, and on a "real" CPU you probably want to do that stuff on microcode, and not in "gates".
Whether the full Apollo core supports these instructions I don't know. But honestly, it is not really a loss, and providing a support library for that kind of stuff does not make the project any worse. It's mostly instructions you would microcode in a "real" hardwired CPU, but microcode is nothing that one can do elegantly in an FPGA, so it wasn't done.
-
Well, actually, one could. Except that the result would be unbearably slow. The problem with the coldfires is that they only support 32-bit math, so every word-based or byte-based arithmetic instruction would require an emulator trap. And there are plenty of them, it's really a pretty common type of instruction on the Amiga.
Last I read was that some instructions were incompatible on the Coldfire that could not be trapped so the code basically has to be run under (JIT) emulation.
-
In a sense, you cannot have everything. P96 support requires 68020 support. Some games break on a 68020. Fast execution requires higher clock rates. Some games break on faster processors. At some point, you probably just have to say, ok, I'll boot this game with the plain old 68000 in the system.
An FPGA allows you to load a 68000, 68010, 68020, 68030, 68040 or 68060 core depending on what you need at the time. AGA Amigas don't have a 68000 to fall back to, some Amigas don't have any CPU to fall back to.
At some point somebody that doesn't want to redefine the ISA will come along and do it right and we can all buy that one with confidence.
-
What is the truth? Can you tell us when you change your mind again and update your documentation (the only documentation I find is N68050 encoding maps)? The truth can change especially where you control it. The last truth (or lie from your posts) was that you were using OPI.L #.W, which would partially overwrite encodings of some other instructions like CAS, CAS2 and CMP2.
Matt,
The Phoenix development team does meet every day in IRC channel.
The team members are therefore informed and have good overview.
Matt if you are never in IRC channel, you can not know what is going on.
If you want to know more you need to participate.
The Phoenix development team has access to complete instruction decoding definition.
But you are not part of the development team,
therefore you have no access to this - so how can you know them?
The team members have hardware card and use Phoenix.
So the team members can speak from practical knowledge.
But if you have no card and never used Phoenix - then you have no practical knowledge.
Matt you look at the project from on outside view.
There is nothing wrong with this.
But don't you agree that from your outside view you can not really know anything about Phoenix?
And do you not agree that as long you lack overview, and have no real knowledge - you can also spread rumours.
But spreading rumours and false information is really not helping the people at all.
-
if an amiga has not enough backward compatible cpu to satisfy your needs, it could fall back to, then its not gunnars fault. its likely that if if there will be hardware available, there may appear some alternative cores for it.
so far there always has been a lot of talking about fpga for years but very few people who actually did anything. not sure if there is an alternative for gunnars solution any soon, alas. which is uncomfortable, because there is a bit too much of what depends on one person for my taste but i dont see no option.
-
alas. which is uncomfortable, because there is a bit too much of what depends on one person for my taste but i dont see no option.
Just include me in your good night prayer and all willbe good.
-
@gunnar: who knows to whom i would be praying if i did;)
honestly i hope you wont get hit by a bus any soon;)
-
Lets be happy there is some development for our dream computer - amiga.
-
Indeed! Just keep it rolling Gunnar and we will back you up with money. Please start working on hard drive support, after all a fast CPU needs fast access.
Chris
-
The MacII (and later) all run in Supervisor mode, not user mode like the Amiga. However, the Mac can jump back and forth. Traps are used to get in and out OS calls. Traps are also used on the Atari ST.
So, as we have learned with the FPGA Arcade Replay project, you just need to support every single 68020 instruction and addressing mode, and then everything works. :)
-
The Phoenix development team does meet every day in IRC channel.
The team members are therefore informed and have good overview.
Matt if you are never in IRC channel, you can not know what is going on.
If you want to know more you need to participate.
Your time zone is 7-8 hours different. A forum is better to provide information if it was correct.
The Phoenix development team has access to complete instruction decoding definition.
But you are not part of the development team,
therefore you have no access to this - so how can you know them?
Why make a public forum with partial and incorrect information posted by you and then keep the current "developer" information private? Use some logic, learn how to communicate and get organized.
The team members have hardware card and use Phoenix.
So the team members can speak from practical knowledge.
But if you have no card and never used Phoenix - then you have no practical knowledge.
Do you really think the majority of Majsta accelerator owners know what enhancements and encodings are in their card?
Matt you look at the project from on outside view.
There is nothing wrong with this.
But don't you agree that from your outside view you can not really know anything about Phoenix?
And do you not agree that as long you lack overview, and have no real knowledge - you can also spread rumours. But spreading rumours and false information is really not helping the people at all.
I don't need hardware to see an ISA or encoding conflicts or what you have written on a forum (although maybe I need an interpreter because you have been anything but clear). I am only unable to test what I see. I would certainly consider buying the hardware if I could get good information and straight answers about the accelerator without wasting my time logging on to the IRC at inconvenient hours.
You called me out and everything but called me a liar but have not provided an answer, explanation or apology to what is probably your error.
Truth is good.
Can you start posting the truth instead spreading false rumours?
What you say is not true.
CAS and CAS2 are supported.
From your forum at http://www.apollo-core.com/knowledge.php?b=4¬e=2732
Lets quickly sum up the available new instructions:
We have two short encodings which reduce program size:
ADDI.L #16bit,(ea)
CMPI.L #16bit,(ea)
The 16bit value is sign extended to 32bit before the 32bit operation is done.
Specifically,
ORI.L #d16, does not allow trapping of CMP2.B and CHK2.B
ANDI.L #d16, does not allow trapping of CMP2.W and CHK2.W
SUBI.L #d16, does not allow trapping of CMP2.L and CHK2.L
ADDI.L #d16, no conflicts
EORI.L #d16, does not allow trapping of CAS.B
CMPI.L #d16, does not allow trapping of CAS.W and CAS2.W
While most of these instructions (with these operation sizes anyway) are likely to be rare even on the MacOS (and all should be deprecated IMO), I don't know if they are used on the MacOS so they could pose a problem. I wish Jim Drew had found his list of MacOS instruction frequencies he said he made years ago.
Here is the encoding map which shows the encoding conflicts.
http://www.heywheel.com/matthey/Amiga/68kF1_map.ods
OPI #d16,Rn has no conflicts in any case but there is little advantage when OP.L ,Dn using a new sign extended addressing mode (which who came up with?) allows OP.L #d16.W,Dn and the ISA documentation specifies to use the latter. Most instances of OPI.L #d16, are to a data register which can be converted to OP.L #d16.W,Dn with the exception of EORI.L because of the missing EOR.L ,Dn (uncommon enough that the 68k didn't support it).
Now instead of making me out to be an uninformed liar with your propaganda and falacies, how about letting us know how you performed the impossible of avoiding these encoding conflicts and allowing trapping for all possible 68020 integer instructions the MacOS could use. Are you willing to guarentee that there are no encoding conflicts when using MacOS emulation or you will allow the return of accelerators and personally refund the money of unhappy customers?
-
matt, he hasnt called you a liar. he simply suggested your info may not be up to date imho. that probably since they lack time to update online documentation, which would sure be more convenient than relaying on irc for communication, but then it all takes time.
-
Your time zone is 7-8 hours different. A forum is better to provide information if it was correct.
Why make a public forum with partial and incorrect information posted by you
Matt you to agressive here.
Can you just calm down?
Your problem is that you misunderstand stuff and or misinterpret stuff.
There was nothing is incorrect about the old forum post.
Lets look at the fact first before we start to panic ok?
The forum post did show several instructions.
In fact only the instruction behavior and name was discussed there.
The encoding was never discussed in this posting.
This means the instruction where shown in NAME only not in ENCODING.
Is this correct - Matt?
So we can state here, that the encoding was not shown and not explained.
So in fact you do NOT know the encoding of the instruction.
Nevertheless you post here that the "unknown" encoding would clash with another instruction.
Please explain this.
-
ORI.L #d16, does not allow trapping of CMP2.B and CHK2.B
ANDI.L #d16, does not allow trapping of CMP2.W and CHK2.W
SUBI.L #d16, does not allow trapping of CMP2.L and CHK2.L
ADDI.L #d16, no conflicts
EORI.L #d16, does not allow trapping of CAS.B
CMPI.L #d16, does not allow trapping of CAS.W and CAS2.W
While most of these instructions (with these operation sizes anyway) are likely to be rare even on the MacOS (and all should be deprecated IMO), I don't know if they are used on the MacOS so they could pose a problem. I wish Jim Drew had found his list of MacOS instruction frequencies he said he made years ago.
I looked through even my Syquest cartridge backups and I could not find that info. :(
I can tell you that the MacOS uses ALL of the above instructions.
I will chat with Derek (emulators, inc.) I might have given the instruction frequency info to him when I sold FUSION-PC to his company.
-
Last I read was that some instructions were incompatible on the Coldfire that could not be trapped so the code basically has to be run under (JIT) emulation.
Back in the day I worked on one of the coldfire projects specifically on code compatibility issues.
The exact problem is that there are matching instructions which are completely legal on both coldfile and 68K... BUT they execute different functions. Since these codes are legal, there is no way to trap them in supervisor mode. The 68K code is accepted by the coldfire, but doesn't do what's expected by the OS. (crash)
To catch these few trouble codes (2 if I recall) some other method is needed. Pre-processor one possibility. In the end, any of the solutions greatly increased the complexity and cost of a coldfile Amiga card.
The Atari cold file was successful mainly because their OS didn't use these 2 matching op codes, so they didn't have to worry about them.
Plaz
-
Matt you to agressive here.
Can you just calm down?
I am calm. Do you see one exclamation point, upper case text or bold text from me? You accused me of twisting the truth and I am not supposed to defend myself? I ask questions to uncover the truth and I receive more questions in return. I worked to create an open enhanced 68k ISA and instead you use some of my ideas and analysis to make a secretive ISA. You try to make me look like an outsider who is not capable of understanding the complexity of your ISA yet I have much of it documented better than you. You ignore the suggestions and conclusions of the majority beneath you but make no apologies when you end up using what they suggested after you arrogantly run them off. Some people want a saviour so bad that they are willing to put up with anything but I am wary of the fruits of a false Messiah.
Your problem is that you misunderstand stuff and or misinterpret stuff.
There was nothing incorrect about the old forum post.
Lets look at the fact first before we start to panic ok?
There is no panic but only a desire for the truth which has not been revealed because my questions have not been answered. Your own information spreads confusion unless you use consistent sytax and terminology, give enough information to be clear and update your information when you make changes. The information you have given about your new ISA on your forum is unclear and mostly useless.
The forum post did show several instructions.
In fact only the instruction behavior and name was discussed there.
The encoding was never discussed in this posting.
This means the instruction where shown in NAME only not in ENCODING.
Is this correct - Matt?
That is correct but unlikely as there are not very many good ways to add OPI.L #d16.W, encodings for such a small gain. Also, why keep this info about your ISA secret instead of answering the question about MacOS compatibility?
I looked through even my Syquest cartridge backups and I could not find that info. :(
I can tell you that the MacOS uses ALL of the above instructions.
I will chat with Derek (emulators, inc.) I might have given the instruction frequency info to him when I sold FUSION-PC to his company.
Thanks for looking anyway Jim. I lose stuff I know I still have somewhere. I know the MacOS uses a wider variety of 68k instructions but those instruction frequencies would be interesting. CMP2 was quite rare on the Amiga with WHDLoad reporting patches of only 2 games or demos. CAS and CAS2 (and TAS) were not compatible with Amiga chip set DMA and were documented as illegal on the Amiga so they shouldn't have been used (but a few games used TAS at least). I was for reusing these rare encodings *if* there was a large enough benefit but after analyzing data and considering the importance of compatibility to a retro 68k market, my conclusion was that it is not worthwhile (not that my opinion or vote ever counted).
Back in the day I worked on one of the coldfire projects specifically on code compatibility issues.
The exact problem is that there are matching instructions which are completely legal on both coldfile and 68K... BUT they execute different functions. Since these codes are legal, there is no way to trap them in supervisor mode. The 68K code is accepted by the coldfire, but doesn't do what's expected by the OS. (crash)
To catch these few trouble codes (2 if I recall) some other method is needed. Pre-processor one possibility. In the end, any of the solutions greatly increased the complexity and cost of a coldfile Amiga card.
The main user mode integer problems are:
1) The CF stack is longword aligned where the 68k stack is word aligned.
2) DIVSL/DIVUL incompatibility (68k returns quo+rem while CF returns quo and has REMS/REMU for rem)
3) MULU/MULS incompatibility (68k sets CCR[V] for overflow but CF does not)
Motorola could have sold a lot more CF processors if they had been smart and allowed all 68k instructions to be trapped, set the CC the same for all instructions and allowed a setting for the stack to be either word or longword aligned. They couldn't even do a good job of cutting the 68k to anemic performance ;).
-
I am calm. Do you see one exclamation point, upper case text or bold text from me? You accused me of twisting the truth and I am not supposed to defend myself? I ask questions to uncover the truth and I receive more questions in return. I worked to create an open enhanced 68k ISA and instead you use some of my ideas and analysis to make a secretive ISA. You try to make me look like an outsider who is not capable of understanding the complexity of your ISA yet I have much of it documented better than you. You ignore the suggestions and conclusions of the majority beneath you but make no apologies when you end up using what they suggested after you arrogantly run them off. Some people want a saviour so bad that they are willing to put up with anything but I am wary of the fruits of a false Messiah.................
So what you are saying is: biggun is a scamming us? I am no longer waiting for the vampire and ordering ACA1233 instead because matthey is giving me bad ideas about biggun's project.
-
Motorola could have sold a lot more CF processors if they had been smart and allowed all 68k instructions to be trapped
Thanks for the list. I specifically remember #2 and 3. With those "unsolvable" I never progressed far enough to see #1. .
Motorola's decisions confound me too. Seems it wouldn't have taken much to build a better bridge to legacy 68K hardware especially since there was so much of it all over the world.
@Thread
Interesting and contentious, but so far civil. I hope it continues that more progress is made.
Plaz
-
So what you are saying is: biggun is a scamming us? I am no longer waiting for the vampire and ordering ACA1233 instead because matthey is giving me bad ideas about biggun's project.
No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.
Thanks for the list. I specifically remember #2 and 3. With those "unsolvable" I never progressed far enough to see #1.
#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.
Motorola's decisions confound me too. Seems it wouldn't have taken much to build a better bridge to legacy 68K hardware especially since there was so much of it all over the world.
It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.
-
You accused me of twisting the truth
Matt I did never say that lie on purpose.
I said that you say is tell people not the truth, that you tell people simply wrong stuff.
In this case all you knew was the name of the instruction.
You did not know the encoding.
You have to admit this.
Nevertheless you warned that the encoding will break compatibility.
Matt what you did was not correct.
-
No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.
#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.
It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.
But the way you are hostile and pointing out all his faults and defects and pointing out all his errors and in a way you implied he does not know what he is doing you give them negative light. Personally I want to buy vampire 500 badly, but if you continue in this road you might destroy what potentially a live rescue boat for classic Amiga.
I mean when I read your sentence I sense toxic energy.
-
Lets clear this up:
The Core and ISA definition is available for developers today.
It is NOT available today for download by the public
The reason is that the core is not officially released yet and that the core could still change and improve before release date.
Everyone should be able to understand the benefit of this reasoning.
As good news:
The Core is continously improved:
Yesterday the core was upgraded and can now execute 3 instructions each cycle
Also good news:
The core team with hardware designers had a long discussion and came to the mutual understanding and agreement that all CPU cards from now on will have a minimum FPGA size.
This means all cards for all platform will have a minimum sizes.
This size is big enough to fit the full Apollo core plus the 68k FPU.
This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.
Software developers can write/compile for Apollo as target and this will run on all cards.
All features including FPU will supported both in budget and in high end cards.
-
Lets clear this up:
The Core and ISA definition is available for developers today.
It is NOT available today for download by the public
The reason is that the core is not officially released yet and that the core could still change and improve before release date.
Everyone should be able to understand the benefit of this reasoning.
As good news:
The Core is continously improved:
Yesterday the core was upgraded and can now execute 3 instructions each cycle
Also good news:
The core team with hardware designers had a long discussion and came to the mutual understanding and agreement that all CPU cards from now on will have a minimum FPGA size.
This means all cards for all platform will have a minimum sizes.
This size is big enough to fit the full Apollo core plus the 68k FPU.
This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.
Software developers can write/compile for Apollo as target and this will run on all cards.
All features including FPU will supported both in budget and in high end cards.
Love it! (http://www.femoticons.net/images/posts/adore_emoticon_love.png)
One question. What is the difference between budget and high end cards?
-
The Core is continously improved...
To be honest, I'm personally not too hot about ISA extensions at all. The major problem is here that it segments the platform while not offering a reasonable return. Just consider instructions like EORI.L #...,? What are the intended use cases, and which software would profit from that? Which compilers would support it, which assemblers would? Does it enable any "killer features"?
Let me tell you a bit from my personal experience: In my world (ISO business, WG1), we first make a requirements analysis before we attempt a new "work item". That is: What exactly do you attempt to do, and which requirements does it need to satisfy?
In essence, the ISA modifications up to here do not buy you much, but instead requires potential new software (for the Amiga? oh well...) to potentially distinguish between a legacy Motorola core and the Phoenix core. How will we do that? Another bit in ExecBase->AttnFlags? How many revisions of the core will there be? We might be running out of bits shortly, and it may get more and more inconvenient to update software.
In reality, how many programs did use the new features the newer processors of the Motorola series introduced? Essentially, Motorola only had two ISAs: The original 68K one, and the extended 68020 ISA. Everything between was really minor, and the majority of Amiga software uses the 68K ISA. A small part requires 68020+, but there is almost nothing that is specifically 68060/68040 only. I would prefer if extensions would continue in this tradition.
Instead of adding a series of seemingly nice, but in reality almost useless low-level additions, it would be much more sensible to add higher level functionalities that enable new killer features the Amiga did not have originally, and from which multiple programs could benefit. Say, JPEG decoding or MP3 decoding. None of the new instructions make these tasks simpler, easier or faster - they are too low-level. What it would probably take would be a hardware engine for some of the components of these standards (Huffman decoder, DCT, digital filters... hence, multiply-add instructions, shift-and-mask instructions and so on).
-
Just consider instructions like EORI.L #...,? What are the intended use cases, and which software would profit from that? Which compilers would support it, which assemblers would? Does it enable any "killer features"?
EORI.L #im,EA
If you mean tthe original 32bit form then this an original 68000 Instruction.
All compilers support it since always.
EORI.L #i16bitm,EA
If you mean a 16bit variant of this then this instruction does not exists.
It is NOT a Phoenix Instruction.
We have no plans to support this.
Let me tell you a bit from my personal experience: In my world (ISO business, WG1), we first make a requirements analysis before we attempt a new "work item". That is: What exactly do you attempt to do, and which requirements does it need to satisfy?
Thomas, I agree. We do the same.
The problem here is that some misunformation was posted and this misinformation is causing confusion.
-
To be honest, I'm personally not too hot about ISA extensions at all. The major problem is here that it segments the platform while not offering a reasonable return.
We agree that segmenting the platform is bad.
And actually I think that there is already a unhealthy segmentation existing.
There are Amigas which support MOVE16 and people use this instruction.
There are Amigas which have FPU and Amigas without FPU, and code that uses the FPU.
We want to improve this.
Our new cards will all have 100% the same instruction set.
All cards are designed to support all instructions including MOVE16 and FPU.
I think that this will help to provide are common coding ground.
The cards also offer a lot more CPU power e.g 200 Mips for budget pricing.
I think that this will make coding easier in the future.
-
@biggun Any news on the developer boards? Put forward my interest, is there a time frame that you are looking at?
200mips sounds amazing coming form 100mips on my 060@80MHz I can see the potential.
Looking forward to further updates :-)
-
No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.
#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.
It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.
Matt you start to slightly nerving now. With the next wave there will be a number of new testers (some active here in this forum) who will test and verify it using the newest core. This idelogic debates (by technicians) if more or less registers are better are far from real. You should do that debate by PM or email and not in the public because most people do not understand it and are only getting irritated except you want to harm the project. If that is your goal then go on like you do. BTW as I wrote on apollo forum most of it is to me rather theoretical.
-
I don't mind the debates, some of it is interesting reading. What I don't like is the negativity.
-
I don't mind the debates, some of it is interesting reading. What I don't like is the negativity.
The debates on apollo forum were in the same tone as here (partly worse). Matt can like it or not but decisions and work is not done by him but by Gunnar and some others. At the end the result counts and we will see it when we will have and use the new cards. That debates if one register more or less is better or worse or if without one command the world goes under are nerving. If Matt would want to help he would buy a card and help testing and help to improve compatibility instead continuing the debate from apollo forum on a public forum where people only get wrong impressions.
Regarding ISA extensions I am of the same opinion that supporting existing ISA is more important than extending it because we have only few developers (like Novacoder) left who would really use this new commands. Most others are using compilers. We have a huge 68k codebase with lots of compilers, libraries and applications and games but many of these are closed or written in asm. Who will adapt the compilers? And even when they are adapted many programs are not available in source. So most energy should be invested in getting the most for the existing codebase.
The rest of the debate between Matt and Gunnar was that Matt preferred something different because what Gunnar does would be not best for ASIC and Gunnar denied that. I cannot judge who is right or wrong there and I do not care. Sorry Matt I do not believe that there will be any ASIC design in foreseeable future (high costs) and if someone would really invest in such a project the design certainly could be adapted (assuming that Matt is right at all, Gunnar is working at IBM so he should have some clue too). I want the best for existing FPGAs. Besides I think FPGA is more interesting and has more geek factor than ASIC right now.
-
I hope I gets the chance to buy one card and I love to test it.
-
This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.
So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
Hopefully you will open source it so we can remove them.
-
So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
Hopefully you will open source it so we can remove them.
Huh?
Was that a joke?
-
So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
The ISA extension are 100% compatible with old code.
There are no negative side effects.
All old code will work.
And new code has the option to use them for your benefit.
But no one is forced to upgrade now to a 200 Mips CPU.
If you do not want more Mips, more perfomrance, higher memory bandwidth or faster instructions - simple just keep your old CPU.
-
The ISA extension are 100% compatible with old code.
There are no negative side effects.
There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores. I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.
-
There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores. I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.
what do you mean with old and new core?
old core is existing 68k processors? If the new ISA supports old ISA what is the problem adding new except almost no software will use it?
-
As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it.
Maybe the ISA should really not be discussed here.
Most people do not understand the topic and get only confused.
Regarding forward compatible of old system.
The new card offer performance levels of 68030 systems with 500-1000 MHz.
How sensible is running future games or demanding webbrowser
which will depend on this speed on 16 MHz 68020?
Regarding whether the added value is low or high.
Trust me the added value is HIGH the changes give over 300% speed up in FPU area for example.
I can show you example code which demonstrates this.
If you want more details to understand this - lets move over to Apollo forum.
Here is not the technical audience.
Cheers
-
If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.
What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?
-
Trust me the added value is HIGH the changes give over 300% speed up in FPU area for example.
The added value of the modified ISA is certainly not HIGH. What can you do now you could not do before? Instead, you rather enable people to create incompatible programs that could have been created on the existing platform with only minor modifications and with only a very minor loss of performance.
I know, there is the cycle counter party whose members would sell their grandma to reduce the number of clock cycles in a totally uninteresting part of a program, and maybe you want to address the demand from those folks. However, beware! The outcome of such activitly is usually less useful than one may hope for, leave alone the stability, and the increased performance is usually not what you have hoped for.
Increasing clock speed, caches and so on - these are all forwards-compatible extensions that are well regarded and hoped for. Adding new instructions is not.
-
There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores. I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.
i agree on that, there is no detailed technical expertise to understand this problem.
however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.
@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.
-
If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.
What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?
To whom do you talk?
Phoenix is faster than Coldfire already.
What do you want to fix in software?
-
The added value of the modified ISA is certainly not HIGH.
What is your definition of high?
Is trippling the FPU speed with new ISA high?
-
i agree on that, there is no detailed technical expertise to understand this problem.
however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.
@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.
Sometimes I have problems to understand the problems. All old code should run on it (as fast as possible) and of course when new 68k software is developed (for 68000-68060). Most people will use compilers and not directly write asm so compiler generated code should also work. Then there could compilers be extended to support new commands but that would be only a new compile if you use a high-language and as long as you are aware that this code needs apollo I do not see a real problem. If someone writes asm he certainly knows anyway what he does. There should be documentation then what is supported by old ISA and what is only available on new ISA. And the programmer then has to decide. But in general I do not see a real problem. I think technicians sometimes are lost in the wood nobody else even see and are only irritating others by becoming ideologic/religious about it (what it sometimes seem to me).
-
i agree on that, there is no detailed technical expertise to understand this problem.
however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.
@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.
Might be that many programs are not benefitting from it because they were compiled with compilers not supporting these new instructions or even written in asm not using this commands but I do not understand why it is a real problem as long as 68000-68060 code works on it. Who wants to use the new commands has either use new compilers (with a new apollo target) or write it himself in asm. As long as people are aware that apollo specific code not necessarily runs on 68000 I do not really see the problem. Anyway hopefully apollo (+new chipset) becomes the new standard and nobody will then care about a plain A500 when developing a new software. I think there of demanding applications and games, who will try to run them on such hardware anyway?
-
@olaf
i hope the extension wont become a new standard as long as they are proprietary.
-
What is your definition of high?
Is trippling the FPU speed with new ISA high?
You're mixing two things here: Added speed (which is a forwards compatible extension) and extended ISA (which is not a forwards compatible extension). The added value of more speed is high. The added value of an extended ISA is low (who would use it anyhow, and if so, how?)
-
With (large enough) FPGA you can go on extending, the core adding new features and end users can upgrade to the new core. There could be an annual release cycle for improvements in the core for some years to come. This allows a "new generation" of "classic" Amigas or "NG Classics". They still run ALL the classic software natively (chipset/bad code limitations may still apply) and also run ALL "NG Classic" software like web browsers, video players, 3D Games etc. "NG Classic" software will NOT run on "classic" Amigas without installing an upgrade card but so what! AGA software doesn't run on OCS/ECS either currently. It would be foolish to not take the opportunity of upgrading the "CPU" with an improved ISA just because the code will not run on Motorola/Freescale "CPU" limited Amigas.
-
You're mixing two things here: Added speed (which is a forwards compatible extension) and extended ISA (which is not a forwards compatible extension). The added value of more speed is high. The added value of an extended ISA is low (who would use it anyhow, and if so, how?)
Thomas
you misunderstood my point
With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.
This means NEW ISA makes huge impact.
I can show you example code showing this.
-
You're mixing two things here: Added speed (which is a forwards compatible extension) and extended ISA (which is not a forwards compatible extension). The added value of more speed is high. The added value of an extended ISA is low (who would use it anyhow, and if so, how?)
i think its possible that people will use it. the main problem imho is similar to warpos situation. its backwards compatible. you can run pure 68k code on it. but in order to gain advantage of speed you need to compile binary that wouldnt run on pure 68k system. the closed proprietary nature of the system led to its limited popularity and to the situation that support for available hardware like sonnet has been unavailable for decade and must just be researched by the means of reverse engineering and full reimplementation. while in this situation being of little use, it added to drain the development resources, that otherwise might have been used for more common goal, even if this aspect may not be as dramatic at second view.
-
The new ISA will be documented at the user level. Implementation will be proprietary just as it was for Motorola.
-
The new ISA will be documented at the user level. Implementation will be proprietary just as it was for Motorola.
im fine with that. though you will agree, that closed source nature of motorola cpu technology and them breaking compatibility by giving up on 68k isa has definitely contributed to amiga hardware being dead end?
-
Motorola giving up on 68k and moving to CPU32/Coldfire/PPC/ARM was a major blow for the Amiga at a time when Commodore/Amiga International didn't have the resources to handle it. Amiga development has stalled until FPGAs have become powerful and cheap enough to pick up where Motorola left of.
-
For a long time software for Amiga has come released in more than one version. For example... 68000 and 68020 versions. Wouldn't it be possible for developers to continue this practice with an additional release option for Apollo card owners? Or am I misunderstanding this part of the discussion?
That being said, how would a compiler deal with new features added to Apollo? In the case of 68K vs 020 versions, it was basically a compiler switch option.
And maybe that second question belongs over at the techie Apollo thread.
Plaz
-
@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?
-
Wouldn't it be possible for developers to continue this practice with an additional release option for Apollo card owners?
Probably, if all versions of the Apollo shared the same ISA. It could get messy fast trying to cope with all the different options. My guess is that it will continue to change for some time yet but only Gunnar can say if that will be the case.
-
For a long time software for Amiga has come released in more than one version. For example... 68000 and 68020 versions. Wouldn't it be possible for developers to continue this practice with an additional release option for Apollo card owners? Or am I misunderstanding this part of the discussion?
That being said, how would a compiler deal with new features added to Apollo? In the case of 68K vs 020 versions, it was basically a compiler switch option.
And maybe that second question belongs over at the techie Apollo thread.
Plaz
I am not a compiler developer but I think it would be a added switch
-
Probably, if all versions of the Apollo shared the same ISA. It could get messy fast trying to cope with all the different options. My guess is that it will continue to change for some time yet but only Gunnar can say if that will be the case.
Public release need to be limited to major milestone versions and bug fixes only. Beta releases are another matter, assembler/compiler writers and beta testers should have access to more frequent releases.
-
@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?
To which Coldfire you want to be compatible?
Which model - which Coldfire ISA?
For me to understand - Can you explain why you want this?
-
Thomas
you misunderstood my point
With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.
This means NEW ISA makes huge impact.
I can show you example code showing this.
Gunnar, please. Are you telling me that the core runs at a faster speed because you added instructions? I beg your pardon...
-
With (large enough) FPGA you can go on extending, the core adding new features and end users can upgrade to the new core. There could be an annual release cycle for improvements in the core for some years to come.
Are you seriously believing a majority of users will do that? And that software X no longer runs because user Y forgot to upgrade the CPU core? Or did upgrade the CPU core? That's a *major* headache for any software provider, and *NO*, I will certainly not do that with my code. That's all 68K-only, with some minor exceptions where it really makes a difference, and I'm not providing an annual software patch because somebody removed a special instruction I was silly enough to use at some point. I'd rather stick to plain 68K instead then. Let's not make another "DLL Hell" by making software developers shooting at a moving target, even less so on a platform that lives from legacy software.
-
Gunnar, please. Are you telling me that the core runs at a faster speed because you added instructions? I beg your pardon...
I'm not sure what is not to understand about this.
For here just accept the truth - new ISA will double and tripple performance in certain areas.
I have the feeling the forum here is not the best place to explain.
Lets go to the whiteboard now..
If you have time just give me a call I'm happily explaining it then to you.
I'm sure on the phone all we be crystal clear for you in matter of minutes.
-
by making software developers shooting at a moving target,
Come on Thomas what wrong here.
Is today "the offical day of misunderstanding people" ?
His point was very clear to me.
And his point makes good sense.
For example:
The situation to get a CPU card today.
And next year install a "flash update" which adds a FPU.
And next year after install " flash update" which adds some SSE instructions.
This is perfect for the users.
Imagine you could have turned your 68000 per flash update into an 68020 and then into a 68060.
Wouldn't this have been wonderful?
He never said that an update will remove anything.
This is really a silly thought IMHO.
-
Come on Thomas what wrong here.
Is today "the offical day of misunderstanding people" ?
You probably use the term "ISA" in a non-standard way. For me, it is the user-observable instruction set, completely with the encoding and the desired outcome and side-effects of each instruction. The ISA does not define the caching, speed, branch-prediction, prefetch-logic and so on because this does not change the programming logic. Any work on these issues is highly appreciated and well-motivated, don't get me wrong. But please, keep your hands from the instruction set, i.e. anything that makes software incompatible - either forwards or backwards.
And next year install a "flash update" which adds a FPU.
And next year after install " flash update" which adds some SSE instructions.
This is perfect for the users.
And a nightmare for any software provider. Gunnar, we are not talking about the intel enterprise here were we have enough market share to force software companies into using another random extension. It's a very small scene, and as soon as instructions are added, you are also creating incompatibilities.
Thus, in specific, using some "unused encoding" from the existing MC68K instruction set is a big no-no. Instead, Motorola had a clear interface how to extend the programming model,and these are the co-processor instruction slots. Whatever extension there is, it somehow needs to go into a documented set that is available for specifically this particular purpose, and not somewhere else. There need to be a documented way to find such extensions, and register them in the Os. The 68060 PCR register was a good start for that. Just randomly throwing instructions into some unused spots is IMHO a very bad idea.
Who knows which instruction set Joe User has loaded today? Do I really need to test all the instructions for availability? Do I really need "another move with zero extension to get a job done faster"? Or which job gets faster by this instruction in particular?
I highly doubt that this is a useful exension given that the focus is on legacy software.
I probably need for *some* specific tasks *some* specific extensions. A multiply-add-capable eight-fold vector logic would be a nice addition for a JPEG DCT, for example. But please: Allocate a co-processor ID for that, and do not throw that into the slots of the FPU or we're creating a big mess of incompatible extensions. Imagine you could have turned your 68000 per flash update into an 68020 and then into a 68060.
Wouldn't this have been wonderful?
For whom? For me as a software developer, this is a nightmare. Oh, your software does not run today? So which core did you flash now? No, this core does not work... use one with SSE, but the cache we do not need this big? Oh, that's then slowing down your favourite game? Well, bad luck, then I cannot support you....
It's very simple: The more you go towards hardware, the more stable the interfaces you provide have to be. Given that the Os cannot move much carrying all the legacy cruft around, how much do you think can the CPU change? For me this sounds like "almost not at all".
So once again: Extensions - yes. But please, not in the general integer logic by mis-using "spare slots" for neat instruction encodings. No program gets seriously faster by "move.b d0,d(PC)" or "move byte zero-extended into d0". That's just polluting the instruction space and fragmenting the CPU landscape. SSE, yes, vector units, yes, ... but please each in its coprocessor space were it belongs, with a flag I can easily test.
-
Which compilers would support it, which assemblers would? Does it enable any "killer features"?
Matt Hey has been ready for years now, with 1 or more assemblers revved up and ready to go as soon as Gunnar publishes the official bitmap list of all the instructions.
Instead of adding a series of seemingly nice, but in reality almost useless low-level additions, it would be much more sensible to add higher level functionalities that enable new killer features the Amiga did not have originally, and from which multiple programs could benefit. Say, JPEG decoding or MP3 decoding. None of the new instructions make these tasks simpler, easier or faster - they are too low-level. What it would probably take would be a hardware engine for some of the components of these standards (Huffman decoder, DCT, digital filters... hence, multiply-add instructions, shift-and-mask instructions and so on).
...
I know, there is the cycle counter party whose members would sell their grandma to reduce the number of clock cycles in a totally uninteresting part of a program, and maybe you want to address the demand from those folks. However, beware! The outcome of such activitly is usually less useful than one may hope for, leave alone the stability, and the increased performance is usually not what you have hoped for.
The 2 main ways to speed up a program are A) cycle-counting to cycle-optimize things and B) rewriting the algorithm from the ground up to be more efficient.
We are not allowed to rewrite the mp3 algorithm or the jpeg algorithm or the h264 algorithm or the h265 algorithm. So the ONLY thing we can do to speed up our software right now is to do the cycle-counting tricks. The best way is to add new instructions to the ISA.
All the asm coders on the Natami forum asked for "Multiply-add with clipping" instruction(s) because they allow a dramatic speed increase for audio and video codecs. Iirc it applies to jpeg decoding also.
Does the Apollo Core have a MADD instruction? When I left off years ago, Gunnar wasn't allowing it. But maybe he changed his mind now? I asked to read the instruction manual to find out but Gunnar hasn't provided it yet.
Sadly without a list of the new instructions, and their bitpatterns (sometimes referred to as opcodes) I can't go around saying how great the new ISA is when I don't even know what it is.
-
I'm not sure what is not to understand about this.
For here just accept the truth - new ISA will double and tripple performance in certain areas.
I have the feeling the forum here is not the best place to explain.
Lets go to the whiteboard now..
If you have time just give me a call I'm happily explaining it then to you.
I'm sure on the phone all we be crystal clear for you in matter of minutes.
Hi Gunnar
First of all congratulations for your progress with your Apollo core.
I think Thor means that existing software won't be rewritten (as the rest of 99% of Amiga software) to use the new ISA so it won't take advantage of newer instructions.
Matthey prefers to take a conservative approach with ISA changes making it more similar to Coldfire etc so compiler changes are accepted in main GCC tree.
Most demanding 1% software like video players and web browsers may be rewritten to use your newer ISA so adding it may be useful as long as it's incorporated in main GCC tree.
I would love 68060 compatibility including MMU support (as long as it's supported by MMU.library I don't care if it's not 060 compatible). I guess that for emulators and monitoring screen updates it's more interesting to have small memory pages like 030 but I'm clueless about MMUs.
when you talk about SSE do you think that making the ISA 56002 compatible may make sense? or something like Altivec?
BTW, I think your team should perform benchmarks with existing optimized 060 software
Good luck
-
A multiply-add-capable eight-fold vector logic would be a nice addition for a JPEG DCT, for example.
Well at least we can all sit around the campfire singing kumbaya because we all can agree on that 1 sentence. :)
-
Who knows which instruction set Joe User has loaded today? Do I really need to test all the instructions for availability?
hmm you seem to got it wrong again.
No one said that stuff get ever removed or replaced.
We talk here about the possibility to complete and improve while keeping all previous features.
We spoke here about shipping core today as Integer core.
Then in 6 month provide FPU upgrade.
The interger core does not "loose" anything then.
Then maybe 6 month later add "mmu" including both FPU and full Integer core.
So "the only way is up" - nothing gets removed here.
-
So, MacOS in emulator works now?
-
So "the only way is up" - nothing gets removed here.
I'll keep this quote for the time you make some incompatible change. But honestly, why all the "extended integer unit". What's that stuff good for?
-
With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.
It seems like a bait and switch. Yeah you can have 400mhz 68060 speed, except you need to port your code to it and the new code won't run on a real 68060.
If you can only make it faster by changing the instruction encoding and therefore having to rewrite all the apps, then putting an x86 or arm in there would make more sense as they could then run at ghz speeds.
-
All the asm coders on the Natami forum asked for "Multiply-add with clipping" instruction(s) because they allow a dramatic speed increase for audio and video codecs. Iirc it applies to jpeg decoding also.
Yes, sure. So that's a useful addition, and welcome. There is a use-case, there are requirements, so add it as a special unit near the FPU.
However, can anyone explain me the use case for "move.l dx,d(PC)", or the use case for "move zero extended to register"? Sure, that's probably all neat, but the number of applications where such an instruction is useful to increase the speed by an amount that makes an observable difference is near zero. Leave alone without new compilers or assemblers around. Yes, I can imagine that for special applications like decoding a hand-tuned inner decoder logic could be tremendously useful and worth the manual work. But seriously, is anyone saying "Ok, I'll now rewrite my application because I have now a move to dx with zero-extend instruction available, and THAT was exactly what I was missing?".
IOW, the integer instruction set has been polluted by a lot of mostly useless stuff that doesn't help anyone a bit, instruction space that could probably been used for something more sensible. Extensions, yes. But then please, make sure that they are good for something and there are clear requirements what these extensions are good for.
-
Come on Thomas what wrong here.
Is today "the offical day of misunderstanding people" ?
His point was very clear to me.
And his point makes good sense.
For example:
The situation to get a CPU card today.
And next year install a "flash update" which adds a FPU.
And next year after install " flash update" which adds some SSE instructions.
This is perfect for the users.
Imagine you could have turned your 68000 per flash update into an 68020 and then into a 68060.
Wouldn't this have been wonderful?
He never said that an update will remove anything.
This is really a silly thought IMHO.
I would love to be able to do that, I don't see the issue with this. Why are we even saying this is a bad thing?
I don't understand the negativity, price is right, performance is right and being able to slowly add features by firmware update?
A Amiga owners dream.
-
I would love to be able to do that, I don't see the issue with this. Why are we even saying this is a bad thing?
I don't understand the negativity, price is right, performance is right and being able to slowly add features by firmware update?
A Amiga owners dream.
Exactly. There is nothing more orgasmic than going to a site, downloading the new firmware and upgrade your card....through workbench screen :D
-
I would love to be able to do that, I don't see the issue with this. Why are we even saying this is a bad thing?
I don't understand the negativity, price is right, performance is right and being able to slowly add features by firmware update?
A Amiga owners dream.
I totaly agree. I am totaly speechless when reading this negativity that I have been reading in this thread today. Tought every amiga user wanted something new. And now we soon will have it and how does some react.....
-
negativity? discussion and feedback is necessary especially if we all want the project to succeed.
-
@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?
I don't think anyone involved with the Phoenix/Apollo project has considered a software library for 100% ColdFire compatibility up to ISA_C (excluding MAC, EMAC and FPU) but it could be done if there was a specific purpose and enough demand. The focus was to make CF as instruction level (not necessarily binary) compatible as practical. Assembler source code could be converted through the use of aliases and macros but some hand modification would likely be required. For example, MOV3Q is in A-line which is not good for 68k compatibility but an ISA alias could convert it to assemble as a new sign extended longword addressing mode. It would be helpful for CF compatibility if the stack (A7) alignment could be configured to word or longword alignment but I don't know how difficult this would be to do in hardware. The DIVSL/DIVUL encoding conflict and different CC flags for multiplication means that it is not possible to have 100% binary compatibility for CF in an enhanced 68k CPU.
To which Coldfire you want to be compatible?
Which model - which Coldfire ISA?
For me to understand - Can you explain why you want this?
There are libraries of ColdFire code and compilers which are more modern than what the 68k has. There is a ColdFire embedded market which is larger than the total 68k market (although probably shrinking) and needs a replacement which could be Phoenix if it was compatible enough.
It seems like a bait and switch. Yeah you can have 400mhz 68060 speed, except you need to port your code to it and the new code won't run on a real 68060.
For compiled code to take advantage, the compiler support and backend code would need to be updated. Adding FPU registers can be done in an orthogonal way (as I proposed anyway) which would make this job much easier. The main changes would be interleaving the FPU instructions using the additional registers and coming up with an ABI which passes FPU registers to functions instead of using the stack. I created the vbcc vclib m060.lib math library, fixed a lot of bugs and added many new c99 math functions in a few months. There could be issues with precision in the vclib code (based on the 68060FPSP) if Gunnar reduces the FPU to 64 bits. Extended precision allows to avoid tricks which are needed to maintain maximum precision with 64 bits only. Personally, I would prefer to stay with extended precision for compatibility but double precision is considerably faster in an FPGA.
However, can anyone explain me the use case for "move.l dx,d(PC)", or the use case for "move zero extended to register"? Sure, that's probably all neat, but the number of applications where such an instruction is useful to increase the speed by an amount that makes an observable difference is near zero. Leave alone without new compilers or assemblers around. Yes, I can imagine that for special applications like decoding a hand-tuned inner decoder logic could be tremendously useful and worth the manual work. But seriously, is anyone saying "Ok, I'll now rewrite my application because I have now a move to dx with zero-extend instruction available, and THAT was exactly what I was missing?".
While I see limited use for PC relative writes, I think the encoding space used can not effectivly be used for other purposes and the protection provided by not allowing PC relative writes is a joke. I doubt compilers would bother with creating a new model like small data or small code but it should be possible to make tiny programs a little smaller and more efficient with PC relative writes opened. I would be willing to go along with whatever makes the 68k most acceptable.
The ColdFire MVS and MVZ instructions can be used very effectively by compilers and peephole optimizing assemblers (an important considerations of an ISA). The support is already available (ready to turn on) as most compilers share the same 68k and CF backend. I'm confident that Frank Wille could have support working in vasm already with a partial benefit in a matter of hours. Turning on the backend CF generation would be a little more work but requires more testing. Sure, it's not going to make a major difference but few integer ISA changes will (exceptions improve branch performance). The applications are obvious enough. Look at the code your layers.library produces and see how many places the MVS and MVZ instructions can be used. The intuition.library is another example where these instructions would be very useful. Of course, the gain is probably only going to be a few percent in performance and code density but it's easy as compilers can use it. Some code would barely use them at all though.
I'm surprised you never got into compilers. Your assumptions may be true most of the time but sometimes the 68020 addressing modes and ISA changes do make a big difference. For example, you say the 64 bit multiplication instructions are rare and they are for SAS/C but GCC has been using them since the '90s to convert division by a constant into a multiplication. Simple code like the following compiled for the 68020 with GCC will generate a 64 bit integer instruction.
scanf("%i",&d);
printf("d / 3 = %d\n", d/3);
The GCC optimization saves quite a few cycles. The 68060 ISA designers failed to recognize that GCC was already using this effectively. I'm working on a similar but improved magic number constant generator which I hope can be incorporated into vbcc. It's possible to use magic number constants for 16 bit integer division which GCC does not do. I may be a cycle counter because I know cycles add up but I still go after the big fish. I pay close attention to what compilers can do and where they fail. One thing I can't fix is where programmers fail. Another example of where the 68020 makes a huge difference we recently fixed in vbcc. The current vclib is compiled only for the 68000 like you think is good enough for your programs. Using ldiv() generated 4 divisions (lacking the 68020 32 bit division instrucitons and doing a division for the quotient and again for the remainder) and included a 256 byte table used for clz (lacking the 68020 BFFFO instruction). The next version of vbcc should have 68020 and maybe 68060 compiled versions of vclib but I fixed ldiv() for now with a single inline DIVSL.L in stdlib.h when compiling for the 68020+.
It is important to consider what the compiler developers think. They know what they need and can use. They should be part of the process of ISA development but the hardware developers (or should we say Gunnar) dictates what they will get. We can see that the ISA creation process has become secretive as can be seen by Gunnar refusing to answer questions in public (I showed how it is possible to mark an ISA with a disclaimer saying that it is for evaluation and subject to change). I tried to create an open ISA early for debate to try to avoid exactly these types of problems but most of the feedback I got was "there is no need yet". Even if my foresight is better than most people's hind sight, it wouldn't do me any good because nobody listens to me no matter how right I am. The truth doesn't seem to matter anymore.
-
I'll keep this quote for the time you make some incompatible change. But honestly, why all the "extended integer unit". What's that stuff good for?
If you don't like it, don't use it or buy. No one is forcing you to participate in testing or making you purchase it. You obviously have a personal axe to grind based on some of your comments or you feel you could do a better job than Gunnar. If that's the case, then put up or shut up.
-
And a nightmare for any software provider. Gunnar, we are not talking about the intel enterprise here were we have enough market share to force software companies into using another random extension. It's a very small scene, and as soon as instructions are added, you are also creating incompatibilities.
Seriously? Amiga hobbyists, tinkerers and programmers are in most cases intelligent enough to use said extensions or to avoid them completely. And who would be forcing you or any other programmer to use the new CPU extensions that Gunnar is adding? You act as if Gunnar would be standing with a gun to your head or something. Again, if you don't want to use them, then don't use them and stop coming up with pointless arguments for the sake of being difficult!
As for incompatibilities, again, which ones? Old software won't be calling any of the new extensions so your argument is moot.
If you feel so strongly about what Gunnar is doing, then why not participate in the testing and help him develop an even better solution rather than slinging mud?
-
If you don't like it, don't use it or buy. No one is forcing you to participate in testing or making you purchase it. You obviously have a personal axe to grind based on some of your comments or you feel you could do a better job than Gunnar. If that's the case, then put up or shut up.
Neither - nor. Nor do I have an axe somewhere. The problem when modifying the ISA is the value/price ratio. The value of the above extensions are minimal, the cost is potential software incompatibility, potentially causing a lot of useless support requests for whomever creates software. There are really better ways to spend the ISA space.
Really, Gunnar and I chat frequently, and friendly. But that still does not mean that one cannot have an argument from time to time. I personally would not extend the ISA in that way, or at least for so little returns.
-
Seriously? Amiga hobbyists, tinkerers and programmers are in most cases intelligent enough to use said extensions or to avoid them completely.
Unfortunately, history tells another story. And who would be forcing you or any other programmer to use the new CPU extensions that Gunnar is adding?
It's not me who is using such extensions. But it's me whose programs may or may not be impacted by users installing programs that may or may not use such extensions inapprpriately. One thing I have learned over the years is that one can rarely point at a single software and say "look! here is your problem!". It is often a combination of various factors, and another complexity enters now the picture one has to take care of as a developer. That's something I would prefer to avoid.
As a user, this is probably hard to follow, I understand. As for incompatibilities, again, which ones? Old software won't be calling any of the new extensions so your argument is moot.
No, but users might be tempted to install "some software" on old machines, that interacts with some other software on the same old machine - or might not know or care about in which state their board currently is. An ISA has better to be stable. If you feel so strongly about what Gunnar is doing, then why not participate in the testing and help him develop an even better solution rather than slinging mud?
You probably don't know... I wrote the Phoenix support library for the small Vampire...
-
If you don't like it, don't use it or buy. No one is forcing you to participate in testing or making you purchase it. You obviously have a personal axe to grind based on some of your comments or you feel you could do a better job than Gunnar. If that's the case, then put up or shut up.
you obviously dont know, that thor collaborates with gunnar on the project and contributes to it as he did to natami.
-
People all is good here.
Thor and my are old friends so to say.
There is nothing wrong to have a technical agree or disagrement sometimes.
Thomas point is that as soon you have a new CPU people might compile software tuned for it.
In the old days we had this problem.
People compiled some application for 68020.
Lets say for example AmIRC, which is not really a CPU eater.
It should run also on 68000.
But compiled for 020 so won't run on 68000.
I think this is the point of Thomas.
That maybe some applications for which a 68030 would be fast enough
will be compiled for Apollo and the executable will not on 68030 anymore.
I fully agree with Thomas that this would be stupid and unneeded.
I agree with Matt that a few percent improvement here and
a few percent improvement there will add up.
Some instruction like MVZ will give a percent more speed here and there,
and better Register usage will give some percents too.
Maybe we get 10-15% more speed this way.
10-15% more speed might not sound much,
but mind that the 10% would already the speed of a full 68030@50Mhz.
I think there will be cases where its all or nothing.
Like for example a h264 decoder. There are usecases
where we know that no old system it fast enough to use them in a sensible way.
Then compiling for Phoenix and getting 15% more speed makes sense.
-
I don't think anyone involved with the Phoenix/Apollo project has considered a software library for 100% ColdFire compatibility up to ISA_C (excluding MAC, EMAC and FPU) but it could be done if there was a specific purpose and enough demand.
I wonder what that would be good for. Are there any serious software applications on CF that are worth looking at? CF is rather an embedded processor, and as such, rarely interacts with the user in a desktop system. Probably in your washing machine. (-: There are libraries of ColdFire code and compilers which are more modern than what the 68k has. There is a ColdFire embedded market which is larger than the total 68k market (although probably shrinking) and needs a replacement which could be Phoenix if it was compatible enough.
Question would be whether there is anything valuable in the libraries that can be used in Amiga application - and worth the incompatibility. For compiled code to take advantage, the compiler support and backend code would need to be updated. Adding FPU registers can be done in an orthogonal way (as I proposed anyway) which would make this job much easier.
And break the exec scheduler, and programs - mostly debuggers - that depend on the stack layout of the exec scheduler. If you want to extend the FPU, it must be done in a backwards (or rather forwards) compatible way, i.e. programs that use only 8 registers continue to use the same register layout in exec. There could be issues with precision in the vclib code (based on the 68060FPSP) if Gunnar reduces the FPU to 64 bits. Extended precision allows to avoid tricks which are needed to maintain maximum precision with 64 bits only. Personally, I would prefer to stay with extended precision for compatibility but double precision is considerably faster in an FPGA.
Me, too... If you want precise low-level arithmetic, you sometimes need access to some of the lower-order bits, i.e. for 64-bit math, one needs three additional bits to avoid round-off errors. The Mot-CPUs of course have these bits internally when they manipulate the registers, and round them away when storing the data - but if you need to work on the bits yourself (rarely!), so would want to have access to them. While I see limited use for PC relative writes, I think the encoding space used can not effectivly be used for other purposes and the protection provided by not allowing PC relative writes is a joke.
That is not quite the point. Not having PC-relative writes is a logical and orthogonal choice with the Havard architecture Motorola follows, i.e. separate program and data space. IOWs, d(PC) is a program (code) access and as such *should not* create write cycles. It is a restriction that comes from a higher design principle, and such a principle as leading tradition should hopefully be follwed. I doubt compilers would bother with creating a new model like small data or small code but it should be possible to make tiny programs a little smaller and more efficient with PC relative writes opened.
Question is: Is it worth the potential incompatibilty, i.e. forking the 68K ISA for such little returns? An ISA fork always creates problems in software support and Os support, users installing the wrong code on the wrong machine, not knowing what they have... I would do that only for features that are "worth the investment", and not for minor stuff like that. I would be willing to go along with whatever makes the 68k most acceptable.
Acceptable for whom and for what? I mean, how many users of the ISA will be there? Essentially, only a hand full of Amiga folks. The ColdFire MVS and MVZ instructions can be used very effectively by compilers and peephole optimizing assemblers (an important considerations of an ISA). The support is already available (ready to turn on) as most compilers share the same 68k and CF backend. I'm confident that Frank Wille could have support working in vasm already with a partial benefit in a matter of hours. Turning on the backend CF generation would be a little more work but requires more testing. Sure, it's not going to make a major difference but few integer ISA changes will (exceptions improve branch performance). The applications are obvious enough. Look at the code your layers.library produces and see how many places the MVS and MVZ instructions can be used. The intuition.library is another example where these instructions would be very useful. Of course, the gain is probably only going to be a few percent in performance and code density but it's easy as compilers can use it. Some code would barely use them at all though.
But look, once again: The improved performance by these instructions is rather minimal. The gain in code density is minimal. Is this worth forking the ISA? I really doubt it. Or rather, put in another way: Would anyone be willing to compile a software library in two versions, one with and one without the added instructions, and support both of them, in a "market" as small as the Amiga? I personally would not. So the "cost" is here the support a software vendor has to pay (for users that use the wrong code), and the benefit is "almost not measurable". I'm surprised you never got into compilers. Your assumptions may be true most of the time but sometimes the 68020 addressing modes and ISA changes do make a big difference. For example, you say the 64 bit multiplication instructions are rare and they are for SAS/C but GCC has been using them since the '90s to convert division by a constant into a multiplication. Simple code like the following compiled for the 68020 with GCC will generate a 64 bit integer instruction.
All nice, but again, see above... Different story. Back then, when Motorola introduced the 68020 ISA, the market was active, and market participants had enough power and interest to invest some of their product development resources into porting to the new features. This is no longer the case nowadays. We are talking about a different situation. A small hobby project like this does not have the power to gain sufficient attraction to make it worthwhile.
Probably, allow me to tell you another story: There is another (older) hobby platform, the Atari 8-bits. There were a couple of user-made extensions using the (backwards compatible) 65816 (or so), a backwards compatible extension of the 6502 in this machine. They also added instructions, 16 bit registers... all nice. Never went anywhere, no applications...
You do not get new applications by offering a 64-bit multiply or a "move byte extended" instruction. You get new applications by identifying current holes in the ISA that enable "killer features" and that address clearly identified performance bottlenecks. a "MOVEZ" does not fill a single hole. It's a nice instruction, but only that. Nice. The GCC optimization saves quite a few cycles. The 68060 ISA designers failed to recognize that GCC was already using this effectively.
A 64-bit multiply can, at some point, help a lot with performance (I'm talking about the quantizer in many video/audio/picture codecs, been there, done that). So yes, that is a useful addition. Now, where is where is the bottleneck for other additions? The current vclib is compiled only for the 68000 like you think is good enough for your programs.
68K is good enough in *most* cases. I may, do and will, use in some cases using extensions from the 68020 extended ISA. Rarely, but sometimes. I would probably never compile an entire program for the 68020+ only. I would probably provide, for some applications, specially tuned versions of some critical routines that are hand-optimized, and then add a dispatcher in the code itself. This way, you create a robust application users do not have to worry about which version they have to install.
The Amiga "market" is too small to support "68020+" only programs, leave alone "Apollo only" applications. On more active markets, that is an option, but not here. It is important to consider what the compiler developers think. They know what they need and can use. They should be part of the process of ISA development but the hardware developers (or should we say Gunnar) dictates what they will get.
I don't object, but in the end, also the compiler writers should understand the user base is. Does it even make sense to support an "Apollo tuned" compiler given the small user basis? As said, I as a developer would probably not care, except for specialized instructions or heavy-duty code, and in that case, I would probably not use a compiler in first place. We can see that the ISA creation process has become secretive as can be seen by Gunnar refusing to answer questions in public (I showed how it is possible to mark an ISA with a disclaimer saying that it is for evaluation and subject to change). I tried to create an open ISA early for debate to try to avoid exactly these types of problems but most of the feedback I got was "there is no need yet". Even if my foresight is better than most people's hind sight, it wouldn't do me any good because nobody listens to me no matter how right I am. The truth doesn't seem to matter anymore.
I personally had no problem when talking to Gunnar. But in the end, it's his time he is investing, so it is his project. I neither tell you how to write the compiler, or support libraries for the compiler. All I can ask is to get in contact with him. I don't need to agree with him. I can only give hints, ehem, with my, ehem, usual "charm".
-
you obviously dont know, that thor collaborates with gunnar on the project and contributes to it as he did to natami.
You are correct and I apologize to Thomas for sounding harsh. It's clear now that he wants to avoid the same mistakes that were made in past regarding the progression of 68K processors and the Amiga. But these problems are not restricted to Amigas/68K systems at all. These problems are inherent to any CPU and its forward progression. Intel and the x86 world struggled with these same issues back in the day, especially when the 80286 and 80386 lines were released. The same problems also occurred when programmers wrote x86 code that required an FPU, but an FPU wasn't present. Back in the day, an FPU for an x86 system was an expensive option. The point I'm trying to make is that yes, there are pitfalls, but they aren't show-stoppers. And the beauty of an FPGA based 68K system is that it can be patched at will. If problems are found, they can easily be addressed and the FPGA updated with a new flash. No need to run around with our hair on fire. If Gunnar was committing his design to hard silicon, then yes, I'd understand the concern, but he's using an FPGA for good reason.
-
MacOS in emulation on Phoenix/Apollo, it's like Schrödinger's cat it seems. I'd love to see examples of applications that truly benefit from a fast CPU used with Phoenix, applications like Lightwave 3D, DPaint, Brilliance, Imagine, World Constction Set etc. I seriously do not care about Doom clones _at all_, nor do I care about WHDLoad of games that already work perfectly fine on unexpanded A500. There is one video on Youtube showing X-DVE on Vampire600, and it is totally unimpressive.
-
@above
There isn't really an Amiga market. There would be about three programs that you might actually purchase. The rest would be free utilities.
-
Think it's just time to cut loose and go all out none of this half arsed stuff. It's 2015 time for the MHz to hit 3 figures and then maybe new software and games will start making an appearance.
Just look at all the new games that are released on EAB because of the new cards produced by Jens being readily available.
Again ready to get involved and see where this goes :-)
Oh have a Rev6 A500 and another A500 plus on it's way :-)
-
Think it's just time to cut loose and go all out none of this half arsed stuff. It's 2015 time for the MHz to hit 3 figures and then maybe new software and games will start making an appearance.
Just look at all the new games that are released on EAB because of the new cards produced by Jens being readily available.
Again ready to get involved and see where this goes :-)
Oh have a Rev6 A500 and another A500 plus on it's way :-)
Honestly, I do not mind that after the release of Vampire XXX series that starting from that time and going on all games demand the new CPU even if it is not pure 68k anymore.
I have no objection to that at all. I just want to see new games coming to my A500 again. I...I want to BUY games for my A500. I want that box again, that manual again, that disk again, that price tag again. I spend 70 dollars on PS 4 games...you don't think I can cough up 40 bucks for an Amiga game?? I will treat my A500 as a console that is all. Another console to buy games for it.
I hope this dream actually becomes reality.
-
I just want to see new games coming to my A500 again. I...I want to BUY games for my A500. I want that box again, that manual again, that disk again, that price tag again. I spend 70 dollars on PS 4 games...you don't think I can cough up 40 bucks for an Amiga game?? I will treat my A500 as a console that is all. Another console to buy games for it.
I think there is a market for that too, kind of why I got the Amiga Future sub. I forgot how good it was to read a real magazine.
I also think there is room in the market for new games that take advantage of faster CPUs. I would love to see some more taking advantage of the 030s out there.
Even if they are improvements over the old school platformers like ruff'n'tumble, Bubble 'n Squeak, Bubba 'n Stix or The Chaos Engine I/II. Push what the 030 is capable of.
I'd buy an updated version of any of those especially ruff'n'tumble.
-
I don't think anyone involved with the Phoenix/Apollo project has considered a software library for 100% ColdFire compatibility up to ISA_C (excluding MAC, EMAC and FPU) but it could be done if there was a specific purpose and enough demand. /QUOTE]
If you compare the Coldfire and the 68K general instruction set then
its obvious that Codlfire general Instruction set is much smaller and simpler.
- A good number of Instructions are missing.
- Some Instructions are crippled. E.g MOVEM
- The ALU operations do not support BYTE/WORD/LONG anymore but only LONG.
- The available EA modes are limited, this heavily weakens all Immidiate instructions.
The MAC instruction are specialist. They for example include a MOVE with another OPERATION.
The included move in the MAC is useful for Coldfire as it allows "hiding" memory access time.
For Phoenix this is not needed as Phoenix has streaming detection and can prefetch and will
by itself with normal code already hide memory latency.
Some MAC operation include special operation handling.This is usefull for DSP applications.
This is nice. The Phoenix includes conditional instruction rewrite.
This means the same benefits could already be generated with normal instructions in many casesby the Phoenix core.
So yes the MAC instructions are for some special purpose areas nice.
But Phoenix provides general CPU improvements as the conditional rewrite and memory streaming which add some of the MAC benefits to all general 68k programs already and this automatically.
If you compare CPU architectures then you see that the best Coldfire the Coldfire V4e,
can do 1 ALU operation per cycle - while Phoenix can do 3 operations per cycle.
-
If you compare CPU architectures then you see that the best Coldfire the Coldfire V4e,
can do 1 ALU operation per cycle - while Phoenix can do 3 operations per cycle.
My 68060 @50Mhz can already do 3 operations per cycle.
loop addq.l #4,d0
addq.l #1,d1
bne.b loop
That is 3 entire instructions executed every clock cycle.
This proves my 50Mhz 060 is a 150 MIPS machine.
A 100Mhz 060 is a 300 MIPS speed demon.
-
My 68060 @50Mhz can already do 3 operations per cycle.
loop
addq.l #4,d0
addq.l #1,d1
bne.b loop
That is 3 entire instructions executed every clock cycle.
This proves my 50Mhz 060 is a 150 MIPS machine.
A 100Mhz 060 is a 300 MIPS speed demon.
First of all, prediction a branch its not an ALU operation.
Do 3 ADDs would be three ALU operations.
And did actually measure the above?
-
http://alive.atari.org/alive12/30vs60.php
The above is a good read :)
-
@Gunnar
So you are saying you can do 3 ALU operations per clock? If so, that is awesome!
Do you mean the normal ALU? Or are you counting the EA-Calculator as an ALU? Or ?
And can you do a correctly predicted branch at the same time as these 3 ALU ops?
So that would be 4 instructions simultaneously. And can you do a FPU operation at the same time?
Give some examples. C0derz gotta code! :)
-
Neither - nor. Nor do I have an axe somewhere. The problem when modifying the ISA is the value/price ratio. The value of the above extensions are minimal, the cost is potential software incompatibility, potentially causing a lot of useless support requests for whomever creates software. There are really better ways to spend the ISA space.
Really, Gunnar and I chat frequently, and friendly. But that still does not mean that one cannot have an argument from time to time. I personally would not extend the ISA in that way, or at least for so little returns.
I think sometimes people problems see where no really is
There will be not only a new core but also a (planned) chipset for the card and both will be in development and change over time. So updating will be required in any case. Affected will be software that directly hits the hardware, applications will (hopefully) only use the OS (f.e. AROS 68k) and thus not be affected at all. Games that are planned to run everywhere will also not be affected. So we talk about certain heavy software like a specific browser version or certain games that might make full use. All old 68k software will not be affected either. As long as it is clear what is added every developer can decide if he wants to use new features or not. And users have to update the FPGA regularly anyway (because of both changes of core and chipset).
-
@Gunnar
So you are saying you can do 3 ALU operations per clock? If so, that is awesome!
Not me. Phoenix does 3 ALU operations per clock.
Give some examples.
MOVE.L ($1245998,A0,D7*4),D2
ADDA.L #$00012345,A0
SWAP D7
ANDI.W #$88aa,(-8456,A7,D0*2)
OR.L D7,D2
LEA (18,A1,A5*8),A6
6 instructions = executed in 2 cycle
-
Not me. Phoenix does 3 ALU operations per clock.
:lol:
MOVE.L ($1245998,A0,D7*4),D2
ADDA.L #$00012345,A0
SWAP D7
ANDI.W #$88aa,(-8456,A7,D0*2)
OR.L D7,D2
LEA (18,A1,A5*8),A6
6 instructions = executed in 2 cycle
That is kRaZy! :crazy: That would be like 14 kazillion PPC instructions!
How do I align the code to make it go "down the pipe" 3 instructions at a time?
A) Don't do anything its all 1000% automatic.
B) Code must be aligned to a word address that is evenly divisible by 3.
C) Other?
In real life I don't think I have any "real" code that can execute 3 instructions at a time (in an important time-critical loop) due to dependencies. Its honestly really hard to write code that executes just 2 instructions at a time on 060 due to dependencies. But still this is a nice technological feature. :thumbsup:
I predict a lot of cycle-counters will be selling their Grandmas to code this chip. :)
-
:lol:
That is kRaZy! :crazy: That would be like 14 kazillion PPC instructions!
Lol yes.
And the 68060 needs 8 clocks for the Instructions above which Phoenix can do in 2
often very cool is the below:
BLT .thisway
MOVE.L #$F00FF,D0
.thisway
What do you think how long do the 2 instruction take on Phoenix and on other systems?
-
Lol yes.
And the 68060 needs 8 clocks for the Instructions above which Phoenix can do in 2
So wait. Why exactly do we need a "move zero extended" instruction again?
After all, "moveq #0,d0; move.b (a0),d0" could also be merged into a single "meta"-instruction, right?
Similarly, "move.w (a0),d0;ext.l d0" could also be merged into one instruction....
I see now even less the need to extend the ISA.
-
So wait. Why exactly do we need a "move zero extended" instruction again?
After all, "moveq #0,d0; move.b (a0),d0" could also be merged into a single "meta"-instruction, right?
Similarly, "move.w (a0),d0;ext.l d0" could also be merged into one instruction....
I see now even less the need to extend the ISA.
Can someone please tell me what this assembly source code does?
-
So wait. Why exactly do we need a "move zero extended" instruction again?
If you want to blame someone, then blame Intel its their fault. :-)
Intel did research studies in the 80th and found out that these instructions are very useful.
After all, "moveq #0,d0; move.b (a0),d0" could also be merged into a single "meta"-instruction, right?
Similarly, "move.w (a0),d0;ext.l d0" could also be merged into one instruction....
This is correct.
In theory a smart CPU could fuse this
move.b (ea),Dn
extb.l Dn
and
move.w (ea),Dn
ext.l Dn
Could be fused to be single cycle each
I agree with you that this is an option
This was also my argument that Phoenix could do this in single cycle already.....
-
Great stuff.
What we need is a scriptable assembly language with OpenGL commands.
This would make assembly portable, with OO overloading compatible commands.
We also need complete regression testing for each command to test pass / fail cpu emulation.
Nice info on chip enhancements
http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/graphics-programming-black-book-r1698
-
I see now even less the need to extend the ISA.
Thomas
I understand the idea of in theory being able to run new applications on old hardware.
But to be honest I'm not sure how realistic this hope is.
Please read my points and explain your view on them.
As ou know the new cards are going to have a local RTG Graphic Video card included.
The CPU has very fast access to this memory.
We talk here about direct read /write access from CPU with several hundred MB/sec.
This means direct single pixel manipulation will be very very fast.
Compared to even the fastest AMIGA Zorro card we have here a speed up of 50 times or 100 times.
Yes the local memory access will be 50 or 100 times faster than you Memory Access over Zorro.
As soon new applications use this an runing on old 68060 system with RTG card is hopeless
as the speed difference between new and old system is over 10 times.
This means if you new game or application uses the new card.
Then the frate rate on old system would be so much slower - its will be come pointless.
I assume you see this too, right?
The new CPU is so much faster than we can now look at stuff like H264 playback which is totally senseless to try on old 68030.
So whether there is a new instruction used or not - does not make a difference the new video datatype will anyway not run on old slow 68030.
And also 68060 will be too slow in many cases.
Olaf did ask the a similar question. But you did not answer it yet.
He did ask you what happens if people use the SAGA chipset in their apps?
I agree with you Thomas that a "hello world" does not need any new instructions.
But a "killer app" which we all look forward too like modern webbrowser or good video player
these will anyway out-spec the old system - the whether the use new instructions or not makes no difference the old 68K CPU are simply to slow for them anyway.
Do you agree here or what is your point?
-
The new CPU is so much faster than we can now look at stuff like H264 playback which is totally senseless to try on old 68030.
So whether there is a new instruction used or not - does not make a difference the new video datatype will anyway not run on old slow 68030.
And also 68060 will be too slow in many cases.
When can we see some screengrabs where SASG is used, or is too early. ?
-
not every application needs full screen update in a high frame rate.
though if you want introduce incompatibility to begin with, then what is the point in a 68k type cpu. er than that it looks like similar road the amiga ppc offshots took, being able to execute old code but otherwise promoting completely new binary target. even faster would be probably to put there an x86 with 68k emu.
-
So wait. Why exactly do we need a "move zero extended" instruction again?
After all, "moveq #0,d0; move.b (a0),d0" could also be merged into a single "meta"-instruction, right?
Similarly, "move.w (a0),d0;ext.l d0" could also be merged into one instruction....
I see now even less the need to extend the ISA.
I find it interesting that Gunnar talks about the technical design of the CPU, including assembler examples, but any mention of ISA details or questions about it or MacOS compatibility can't be discussed in public. I see this as hypocrisy and lack of openness. I tried to get you involved in the ISA creation when he was "taking control" but I don't even think you could have stopped him now.
The ColdFire MVS and MVZ instructions can be added in the same encoding location as the ColdFire with practically no compatibility issues for the 68k. I find your complaint about this odd considering how tame it is compared to Gunnar's hole filling encodings for E0-E7, a non-orthogonal A8 and possible use of A-line (goodbye MacOS compatibility).
Yes, you are correct with your equivalent "merged" instructions but these CF instructions can be used on their own destination register also.
MOVEQ #0,Dn + MOVE.W ,Dn -> MVZ.W ,Dn ; 2 bytes saved
MOVEQ #0,Dn + MOVE.B ,Dn -> MVZ.B ,Dn ; 2 bytes saved
SWAP Dn + CLR.W Dn + SWAP Dn -> MVZ.W Dn,Dn ; 4 bytes saved
AND(I).L #$ffff,Dn -> MVZ.W Dn,Dn ; 4 bytes saved
AND(I).L #$ff,Dn -> MVZ.B Dn,Dn ; 4 bytes saved
The latter 2 are vasm peephole CF optimizations (there are more using MVZ and MVS which are less common). Multi-instruction inputs are not allowed for vasm peephole optimizations. MVS at first appears less useful than MVZ.
MOVE.W ,Dn + EXT.L Dn -> MVS.W ,Dn ; 2 bytes saved
MOVE.B ,Dn + EXTB.L Dn -> MVS.B ,Dn ; 2 bytes saved
Compilers like these types of instructions because they are common on modern processors. The 68k and CF backends are shared by most compilers so support only needs to be turned on.
I would prefer to have 68k names of SXTB.L, SXTW.L, ZXTB.L and ZXTW.L like EXTB.L but specifying the type of extend. I would also allow "SXTW.L ,An" for "MOVE.W ,An" to improve orthogonality and description of the operation. Too many 68k compilers have had problems with the sign extension into address registers and none that I have seen have been able to take advantage of this auto word to longword sign extension for optimizations. Compilers have had trouble here and the CF instructions simplify the code.
Instruction folding/fusion has a cost and it doesn't catch reordered combinations. Let's look at your layers.library 45.24 for example.
Statistics
----------------------------------------
Instructions 2 bytes in length = 2574
Instructions 4 bytes in length = 1910
Instructions 6 bytes in length = 88
Instructions 8 bytes in length = 0
Instructions 10 bytes in length = 0
Instructions 12 bytes in length = 0
Instructions 14 bytes in length = 0
Instructions 16 bytes in length = 0
Instructions 18 bytes in length = 0
Instructions 20 bytes in length = 0
Instructions 22 bytes in length = 0
Instruction total = 4572
Code total bytes = 13316
1 op.l #,Rn -> op.l #.w,Rn : bytes saved = 2
3 opi.l #,Dn -> op.l #.w,Dn : 68kF1 bytes saved = 6
3 opi.l #,EA -> opi.l #.w,EA : 68kF2 bytes saved = 6
0 move.b EA,Dn + extb.l Dn -> mvs.b EA,Dn : bytes saved = 0
90 move.w EA,Dn + ext.l Dn -> mvs.w : bytes saved = 180
0 moveq #0,Dn + move.b EA,Dn -> mvz.b EA,Dn : bytes saved = 0
3 moveq #0,Dn + move.w EA,Dn -> mvz.w EA,Dn : bytes saved = 6
0 pea (xxx).w -> mov3q #,EA : bytes saved = 0
0 move.l #,EA -> mov3q #,EA : bytes saved = 0 68kF bytes saved = 0
EA modes used
----------------------------------------
Dn = 743
An = 976
# = 1
# = 57
# = 6
(xxx).l = 2
(An) = 217
(An)+ = 382
-(An) = 163
(d16,An) = 1449
(d8,PC,Xn*SF) = 2
This is from a version of ADis Statistics this "outsider" modified for Gunnar. The first thing that sticks out are the instruction lengths which are very short and why I adamently recommended 3 superscalar integer units which should be a success even if dual ported memory with 2 cache reads/cycle would make it a monster. The results are a little misleading as SAS/C avoids many immediate longword operations like this:
MOVEQ #,Dn + LSL.L #8,Dn (loads 3rd most significant byte)
MOVEQ #,Dn + SWAP Dn (loads 2nd most significant byte)
MOVEQ #,Dn + ROR.L #8,Dn (loads the most significant byte)
Tricks like this shorten the average instruction length but they generate 2 dependent instructions (without instruction scheduling or folding/fusion). It's more efficient and simpler for the compiler to use the OP.L #,Dn especially with a new addressing mode that could sometimes optimize "op(i).l #,Dn -> op.l #.w,Dn". More modern compilers which promote variables to longword show much more savings using a new sign extended addressing mode and MVS/MVZ instructions which are needed for the promotion to 32 bits. Many processors like the 68060 can only forward 32 bit results and are up to twice the performance with variable promotion to 32 bits.
My ADis Statistics find 90 occurences of "move.w EA,Dn + ext.l Dn" which would save 180 bytes with MVS.W and 3 occurences of "moveq #0,Dn + move.w EA,Dn" which would save another 6 bytes with MVZ.W (total number of instruction reduction for MVS and MVZ would be 93). This gives a good indication of how much could be saved with instruction folding/fusion of these popular pairs also. Let's look for additional savings that wasn't caught though.
move.w d0,d7 ; 26e : 3e00
movea.l a3,a0 ; 270 : 204b
ext.l d7 ; 272 : 48c7
move.w ($10,a0),d0 ; 330 : 3028 0010
move.w ($10,a1),d1 ; 334 : 3229 0010
ext.l d0 ; 338 : 48c0
ext.l d1 ; 33a : 48c1
move.w ($12,a1),d2 ; 33e : 3429 0012
move.l d1,d7 ; 342 : 2e01
move.w ($12,a0),d1 ; 344 : 3228 0012
ext.l d2 ; 348 : 48c2
ext.l d1 ; 34a : 48c1
move.w ($44,sp),d7 ; 3f8 : 3e2f 0044
move.w ($46,sp),d6 ; 3fc : 3c2f 0046
ext.l d7 ; 400 : 48c7
ext.l d6 ; 402 : 48c6
move.w ($46,sp),d0 ; 440 : 302f 0046
move.w ($4a,sp),d1 ; 444 : 322f 004a
ext.l d0 ; 448 : 48c0
ext.l d1 ; 44a : 48c1
move.w ($48,sp),d2 ; 44c : 342f 0048
sub.l d0,d1 ; 450 : 9280
move.w ($44,sp),d0 ; 452 : 302f 0044
ext.l d2 ; 456 : 48c2
ext.l d0 ; 458 : 48c0
...
Did someone turn on the instruction scheduler? I think it's helping some but if you want instruction folding/fusing then the scheduler is a problem. The instruction scheduler by itself removes some of the need for the folding/fusion and is probably better overall. The MVS/MVZ instructions also have limited capability to increase the IPC (Instructions Per Cycle) with only 1 cache reads/cycle but they do still improve code density. If 2 cache reads per cycle were ever implemented then they would make a big difference. The MVS/MVZ instructions would have been added to ColdFire after doing code analysis. I wish they had made it into the 68060 where they would have been especially helpful considering the instruction fetch bottleneck of this processor.
I think better ColdFire compatibility would be useful for the 68k and would win some support from ColdFire customers and developers. Just a few days ago, I compiled some code with ColdFire target (-cpu=5329) into my Amiga hunk executable to see what code it produced for someone. It would be nice if I could run the executable and the Amiga could become a CF CPU option and development platform. It could also be a next genation CPU option for the Atari Firebee. The more code and developers the better especially when relatively small changes can gain CF compatibility.
-
For those of you who don't understand what is being discussed, I will now summarize:
Matt Hey has shown up to the debate with a library full of facts and figures and has won the debate on all counts.
Matt shoots.... he scores! Matt Hey FTW!
PlaySound CrowdGoesWild.8svx
-
For those of you who don't understand what is being discussed, I will now summarize:
Matt Hey has shown up to the debate with a library full of facts and figures and has won the debate on all counts.
Matt shoots.... he scores! Matt Hey FTW!
PlaySound CrowdGoesWild.8svx
Hey ChaosLord, do you have any idea where I can buy the latest version of Total Chaos?
Thanks in advance :)
-
A little confusing about all the plans for boards.
In order of time, we should see (but read carefully, because this is part of the plan to confuse the enemy):
1) A developer board with the Arrow Be Micro. It has HDMI, Ethernet, but only 25.000 L.E. This board seemed adequate only one month ago, but the core is grown too much. These boards are almost ready, are few, so they will be used for testing purpose
2) The Vampire 500. It has 40.000 LE, hdmi, ide... seems to me that Igor already purchased the PCB and it is on the way
3) The Vampire 600b. It is the old vampire "upgraded".
At beginning, igor has planned to have 10.000 LE, but later he decided to switch 40.000 LE so it is delayed. No HDMI.
4) A new board from Christoph Hoehne. It should be the developer board with some upgrades and a new design to fit also in the a600 (with a different connector).
5) A new PCI board with the FPGA, to speedup Winuae.
http://www.apollo-core.com/knowledge.php?b=1¬e=2742&x=2&z=aIEhYP
My biggest question though, is: who is "the enemy"?
-
And yeah, pretty weird that it's impossible to get a straight answer to a bolean question; will MacOS work under emulation on Phoenix?
-
Who cares about MacOS??? Anyway, stop trying to shoot Gunnar down and move on.
My epenis is bigger etc like its a school yard or something.
-
possible use of A-line (goodbye MacOS compatibility).
THIS IS NOT TRUE
Matt all encoding which are new are gated with a Apollo-Mode switch.
You know this fact, this was discussed over a year ago.
This means there is no impopatibility old MacOS code.
You should know that ALL your posts about incompatibility are NOT TRUE.
Matt how do you call people which on prupose while knowing better write not the truth?
-
THIS IS NOT TRUE
Matt all encoding which are new are gated with a Apollo-Mode switch.
You know this fact, this was discussed over a year ago.
This means there is no impopatibility old MacOS code.
You should know that ALL your posts about incompatibility are NOT TRUE.
Matt how do you call people which on prupose while knowing better write not the truth?
Hold on a second, I thought this project is about Amiga and not Mac. Why is Matt is focusing on Mac emulation? To me even IF this card does not allow Mac emulation I don't care...I am into improving Amiga hardware to getting modern software for the Amiga system not Mac.
It seem this entire fight is about Mac.
-
Hold on a second, I thought this project is about Amiga and not Mac. Why is Matt is focusing on Mac emulation? To me even IF this card does not allow Mac emulation I don't care...I am into improving Amiga hardware to getting modern software for the Amiga system not Mac.
It seem this entire fight is about Mac.
Yeah, if Matt isn't whining about Macintosh compatibility, he's whining about ColdFire compatibility. He really needs to take his trash talk to a ColdFire forum or start hanging out at a classic Mac site. He's gotten to be more than just tiring. He's either trying to "wow" us with his assembler knowledge or he has a personal problem with Gunnar, or maybe both. Just wish he'd leave it alone.
-
To Thomas,
Thomas I understand your point that new instructions can have
the side effect that new compiles will not run on old CPUs.
This is clear and this is understood.
What I am not understand is how relevant this is in our case.
Lets look at some numbers
Phoenix today can reach over 300 Mips - this means Phoenix is like 20-30 times faster than todays ACA cards.
We see on the horizon the next gen FPGAs.
This means we can have a future roadmap where we know we can create cards with over 1000 Mips.
The performance difference between Phoenix and old 68030 cards is so ridicolous
that I think the wish to run future killer applications on both platforms is pointless.
-
Yeah, if Matt isn't whining about Macintosh compatibility, he's whining about ColdFire compatibility. He really needs to take his trash talk to a ColdFire forum or start hanging out at a classic Mac site. He's gotten to be more than just tiring. He's either trying to "wow" us with his assembler knowledge or he has a personal problem with Gunnar, or maybe both. Just wish he'd leave it alone.
For me...even if Mac emulation is the greatest importance for me and even if this Vampire 500 is 0% mac compatible and I start pounding my head on the table..I WANT MAC, I WANT MAC EMULATION and I start pulling my hair and freaking out like enraged PMS woman...I have the solution to my problem:
A) Burn down the house with the Amiga in it..just because I could not get a Mac emulator that emulates a 20 year old Mac system
OR
B) Have both ACA500+ACA1233 and Vampire installed at the same time.
You will say to yourself...will..how can that be? We know that Amiga 500 hardware is genius...if it detects said CPU in the zorro expansion it simply disables the CPU in the motherboard where the Vampire 500 is installed. Now I boot in full 68k accelerator and here I can run Mac emulation no problem.
If I get tired of the 68k+Mac emulation and I want to use the modern technology with modern RTG, SAGA, etc...I do not need to remove the ACA500 and install it again....that will cause wear and tear on both the card and my A500 computer...what I will do as soon as I turn my A500 on I get the ACA500 menu right? Will...all I have to do is hit F10...and Del to disable the ACA500 card while it is installed in my A500..the A500 resets...the ACA500 is disabled during the entire time it is turned on...and POOOF VAMPIRE 500 TAKES OVER.
When I am finished...i can either turn on Amiga 500 and turn it back on...and use ACA500 mode..or turn off A500 for the day.
IN THE END MY A500 CAN RUN EVERYTHING...from the OLD 68K to the new Phoenix...without any problem!!
CASE CLOSED!!!!!!!!
Guys...can we please move on in the future. Like i said before...if we need past technology...use ACA500+ACA1233...want modern technology, faster than ACA1233, wanna watch movies on Amiga classic, run DOSBox, run VICE, blah blah...switch to vampire 500 (Phoenix) and both of these are installed in your A500. Between menu configuration you can switch between old or new and without needing to remove or install hardware all the time and you get both of the two worlds. So no need to complain here and let Biggun do his job and we enjoy the result, ok?
-
Last post from my side here.
I appreciate technical discussion.
I appreciate any discussion about which enhancements make most sense, about what benefit 100% Coldfire compatibilty can give us.
What I can not stand is that when people try to strengthen their points by posting manipulative lies.
I have a real problem here with how Matt behaves.
Matt posted on some forum that the way we design the CPU/FPU internally would hindern us going for ASIC.
This is pure bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!.
The fact is that Phoenix design proposal here matches 100% what INTEL, AMD and IBM are planning to do for their next CPU generation coming to market in 2 years.
This means our design is state of the art, absolutely modern.
And what we plan to do is perfect for going for ASIC.
Matt posted here 2 times that Phoenix would have problem running MAC-OS.
This is bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!.
I do not understand why Matt on purpose post lies.
This thread started as very valueable post by somoen pointing out the option to get early Developer cards.
Unfortunately this threads quality got quickly worth by off topic post.
And some of these posts are pure lies.
I see no reason for us to continue to talk on this level.
I will not post here anymore.
If people think it makes sense to spread lies then continue without me.
-
@biggun I appreciate the work you are doing and hope to hear more great things coming our way because of it. I can see Phoenix shaking up the classic hardware community in a good way and perhaps some people are scared of this?
Anyway look forward to hearing further updates and hope that I get a chance to take part :-)
-
What I am not understand is how relevant this is in our case.
Lets look at some numbers
Phoenix today can reach over 300 Mips - this means Phoenix is like 20-30 times faster than todays ACA cards.
We see on the horizon the next gen FPGAs.
This means we can have a future roadmap where we know we can create cards with over 1000 Mips.
Very fine then. Why is it then relevant to have new instructions in first place? Let's check what we have:
*) LineA: This instruction space is not usable because MacOs has its Os traps here.
*) More data registers, A8: Not usable in a multitasking Os because exec does not save and restore these on a context switch. For support, the exec scheduler had to be drilled up. Possible, but creates problems with monitors and system tools like Xoper and friends that analyze the exec stack frame. Hence, more problems for software developers and users, instead of less.
*) Instructions like "MVZ": Not useful because they can be replaced by a sequence of two instructions without any additional cost. Ok, the code gets two bytes longer. Big deal.
So in the end, there are no benefits or no usable benefits at the cost of compatibility. The question is: Would anyone use these instructions in new code? If so, new code would be required to compiled for the old instruction set, and the new instruction set. So basically, the user has to know on which system the software is to run - or would receive crashes.
Does it make sense to write a CPU-dispatcher in a program for such small benefits? Likely not. I will not add a dispatcher to save two bytes for some instructions (after all, I would have to duplicate code, thus making things longer instead of shorter). I will not use additional registers because they are not saved and restored by exec.
The only thing were I believe some extra instructions are useful are in highly specialized bottleneck-algorithms where it makes sense to have a CPU-specific dispatcher, and two versions of the same code because it makes a noticable speed benefit for the user.
The performance difference between Phoenix and old 68030 cards is so ridicolous that I think the wish to run future killer applications on both platforms is pointless.
Then why do we need new instructions in first place?
-
Very fine then. Why is it then relevant to have new instructions in first place? Let's check what we have:
*) LineA: This instruction space is not usable because MacOs has its Os traps here.
*) More data registers, A8: Not usable in a multitasking Os because exec does not save and restore these on a context switch. For support, the exec scheduler had to be drilled up. Possible, but creates problems with monitors and system tools like Xoper and friends that analyze the exec stack frame. Hence, more problems for software developers and users, instead of less.
*) Instructions like "MVZ": Not useful because they can be replaced by a sequence of two instructions without any additional cost. Ok, the code gets two bytes longer. Big deal.
So in the end, there are no benefits or no usable benefits at the cost of compatibility. The question is: Would anyone use these instructions in new code? If so, new code would be required to compiled for the old instruction set, and the new instruction set. So basically, the user has to know on which system the software is to run - or would receive crashes.
Does it make sense to write a CPU-dispatcher in a program for such small benefits? Likely not. I will not add a dispatcher to save two bytes for some instructions (after all, I would have to duplicate code, thus making things longer instead of shorter). I will not use additional registers because they are not saved and restored by exec.
The only thing were I believe some extra instructions are useful are in highly specialized bottleneck-algorithms where it makes sense to have a CPU-specific dispatcher, and two versions of the same code because it makes a noticable speed benefit for the user.
Then why do we need new instructions in first place?
to give the question back... as long as it is (and stays) compatible to existing 68k code (and what is created by compilers) does it harm to add things? Even if most software will not use it? Applications will normally run on the OS, either use AmigaOS 3.X or AROS 68k, only some powerhungry applications like a browser might use some special commands to speed up. Games would theoretical benefit most but again if you want something that runs on different platforms like in emulation you will not use it. Compilers will mostly not support it either (no sources available and/or noone who will add support). So in reality we now have endless discussions about a small minority of programs who might be incompatible because using special commands. You can say it is a waste of resources to implement them (in your view) but it is Gunnar wasting his time and as long as it not harms compatiblity to existing code and compilers it is not a problem to me. Or do I understand something wrong? Can you explain me what are your problems with it and where it hurts? I do not understand it. But I am not a asm coder.
-
to give the question back... as long as it is (and stays) compatible to existing 68k code (and what is created by compilers) does it harm to add things? Even if most software will not use it?
Yes, and yes. It creates potentially incompatible programs, confuses the user and pollutes the instruction space. The corresponding codes could probably be used for something more important. There are only little benefits, and there are only small drawbacks, but if you compare one to another, I come to the conclusion that it's not worth adding this stuff.
Only some powerhungry applications like a browser might use some special commands to speed up.
We've just learned that the overall speedup due to these instructions is probably close to zero. So why bother?
So in reality we now have endless discussions about a small minority of programs who might be incompatible because using special commands. You can say it is a waste of resources to implement them (in your view) but it is Gunnar wasting his time and as long as it not harms compatiblity to existing code and compilers it is not a problem to me. Or do I understand something wrong?
It's a problem with the design philosophy I have here. You're not adding instructions to a core by holding your thumb in the air. Oh, the coldfire has these instructions, let's use them... An overall cost/benefit analysis has not been done, or done incompletely, and if you do, you come to the conclusion that there's nothing that would require(!) such instructions in first place. Now, if the design continues with this strategy (or lack thereof), the instruction space will be filled with lots of this stuff, and when we come to the important stuff (by experience from real-world problems), nothing will be left and we'll have a fragmented platform of various possible FPGA CPU-cores that are all slightly incompatible to each other because at some point some developer came up with another "neat new instruction".
That's not a good design principle, even less so for a platform that only lives from old legacy applications - and can only migrate away to something more powerful by having a single unique well-defined architecture.
Can you explain me what are your problems with it and where it hurts? I do not understand it. But I am not a asm coder.
It's not about "coding" at all. For pure coding, this makes no difference. It is about "strategy" and "long term goals". At this time, any such extension is pretty premature and should be left alone, up to the point were concrete demands require an extension. Then, a careful choice of instructions in an open discussion should be started, finally leading in testing and implementation. But only then.
-
So in reality we now have endless discussions about a small minority of programs who might be incompatible because using special commands. You can say it is a waste of resources to implement them (in your view) but it is Gunnar wasting his time and as long as it not harms compatiblity to existing code and compilers it is not a problem to me. Or do I understand something wrong? Can you explain me what are your problems with it and where it hurts?
I think you've summed up the problem quite well except I'm not bothered about gunnar wasting his own resources.
The hurt comes from another fpga project that is taken over by someone pushing their own agenda.
Once someone makes an fpga board that can be configured to run 100% compatible to original Motorola chips then people can buy them with confidence that it won't turn into a mess further down the road. I'm not against optimisations, as long as they don't impact compatibility (which means you can't add registers or instructions to the cpu core).
-
Perhaps you just dont understand that yet another community split (produced by a badly designed ISA) will harm the entire Amiga/Amiga-ish systems one more time.
Why badly designed? Because keeping Classic Mac compatibility, and as suggested, adding Coldfire compatibility will surely attract more users and developers to 68k systems, which means better debugging and better testing, more compiler support, and of course, much more market opportunities.
On the contrary, a badly designed ISA will be only interested to a niche inside a niche of programers, and that comes with a lack of proper compiler support (yeah, you will only have assembler). So you will have software that will only benefit very few users and not the entire Amiga/ish ecosystem.
-
Perhaps you just dont understand that yet another community split (produced by a badly designed ISA) will harm the entire Amiga/Amiga-ish systems one more time.
Why badly designed? Because keeping Classic Mac compatibility, and as suggested, adding Coldfire compatibility will surely attract more users and developers to 68k systems, which means better debugging and better testing, more compiler support, and of course, much more market opportunities.
On the contrary, a badly designed ISA will be only interested to a niche inside a niche of programers, and that comes with a lack of proper compiler support (yeah, you will only have assembler). So you will have software that will only benefit very few users and not the entire Amiga/ish ecosystem.
I think what Thomas means is concentrating on existing core (up to 68060) instead of adding new commands. I understand that but I think Gunnar is a engineer and it is his baby. Thomas did not write that the core is not compatible but there is no real concept behind the extensions. I understand it and I already wrote my view. 100% compatibility is mandatory, if the core should be extended beyond that is discutable but that is Gunnars decision. There will be more testers in near future so more reports what works and what not.
-
If code is compiled for 68000 with an existing/old compiler such as SASCv6, isn't 68K/AmigaOS compatibility guaranteed throughout the Amiga range when fitted with the new forthcoming Vampire cards?
-
If code is compiled for 68000 with an existing/old compiler such as SASCv6, isn't 68K/AmigaOS compatibility guaranteed throughout the Amiga range when fitted with the new forthcoming Vampire cards?
Yes. But given how much code was actually compiled for the 68020 on the Amiga (off your head, how much do you know?) how much sense makes another extension, now that the community basis is a lot smaller than back then?
-
for those who dont understand: running mac emulation on phoenix/apollo core is merely just a test case. i dont think there is "whining". perhaps just a bit too much emotionality here and there.
edit:
perhaps the best thing is to get the test boards underway and let the project gain its own dynamic, which i trust due to reconfigurability of fpga and customer/tester feedback might take a good direction in the end. we have a very competent and well opinioned people on this project. lets face it, investments in a range of around 150.- are worth the risk. i would sure think twice if it was 500.-
-
Yeah, I am the one who brought up Mac emulation, both because it is an excellent compatibility test, and because it is usefull as old MacOS still has plenty of software that is unmatched on AmigaOS.
As of right now though, more pressing issue is that reaction applications in OS3.9 apparently do not run on Phoenix yet, so no Prefs. I am curious if latest workbench.library (which is 020+) works.
The FPU is (or rather, is planned to be) from what I understand, not compatible with existing FPUs, so no benefit for old FPU intensive software like Lightwave 3D, Imagine etc.
No MMU, just talks about some sort of new MMU that Thomas for sure will fix OS support for with his libraries, same Thomas who is highly critical about a lot of the design decissions and who has clearly stated he is not interested in supporting new instrictions. Old software requiring MMU, from debuggers to VMM and whatever, will not work.
No backend support in any compilers, I am curious what plans OlafS3 plans to support the new instructions etc with AROS/m68k when he has no gcc that support it.
Talks about how Phoenix will be so fast that compatibility with existing software is of no concern, which begs the question - why not just use ARM or some other more relevant architecture instead?
Talks about "killer apps" and "modern browsers", yet boards crippled with only 128MB of RAM, a lot of unecessary incompatibility, shunning off OS developers as well as compilator developers.
Talks about "an enemy", whoever that may be.
Lack of openness, lack of documentation and design route that seems totally ad-hoc, and attitudes that have shunned away other developers for years already. All this is main reason why Natami never really happened in the first place.
Conclusion? Gunnar seems hellbent on creating his own dream CPU, which is fine. Less fine is that he also seems hellbent on luring the entire Amiga 68k community into his proprietary trap. Yeah right, good luck with that.
So, I'd love to see more open and colaborative people to do a more usefull and compatible m68k softcore. Which brings me back to - who is this enemy the Apollo team is talking of?
-
Yeah, I am the one who brought up Mac emulation, both because it is an excellent compatibility test, and because it is usefull as old MacOS still has plenty of software that is unmatched on AmigaOS.
As of right now though, more pressing issue is that reaction applications in OS3.9 apparently do not run on Phoenix yet, so no Prefs. I am curious if latest workbench.library (which is 020+) works.
The FPU is (or rather, is planned to be) from what I understand, not compatible with existing FPUs, so no benefit for old FPU intensive software like Lightwave 3D, Imagine etc.
No MMU, just talks about some sort of new MMU that Thomas for sure will fix OS support for with his libraries, same Thomas who is highly critical about a lot of the design decissions and who has clearly stated he is not interested in supporting new instrictions. Old software requiring MMU, from debuggers to VMM and whatever, will not work.
No backend support in any compilers, I am curious what plans OlafS3 plans to support the new instructions etc with AROS/m68k when he has no gcc that support it.
Talks about how Phoenix will be so fast that compatibility with existing software is of no concern, which begs the question - why not just use ARM or some other more relevant architecture instead?
Talks about "killer apps" and "modern browsers", yet boards crippled with only 128MB of RAM, a lot of unecessary incompatibility, shunning off OS developers as well as compilator developers.
Talks about "an enemy", whoever that may be.
Lack of openness, lack of documentation and design route that seems totally ad-hoc, and attitudes that have shunned away other developers for years already. All this is main reason why Natami never really happened in the first place.
Conclusion? Gunnar seems hellbent on creating his own dream CPU, which is fine. Less fine is that he also seems hellbent on luring the entire Amiga 68k community into his proprietary trap. Yeah right, good luck with that.
So, I'd love to see more open and colaborative people to do a more usefull and compatible m68k softcore. Which brings me back to - who is this enemy the Apollo team is talking of?
-
@Thomas Richter
You seem to put a lot of energy into opposing the addition of new instructions added in to Jay Miner Compatible Computers.
I would dearly love to read some of your criticisms of Intel adding in new instructions to Bill Gates Compatible Computers. Where may I read these scathing criticisms?
Intel gets to add new instructions all the time. Endlessly. This must frustrate you terribly. It would be most enjoyable to me to read your crushing rebukes of Intel Corporate Policy.
If you could provide a link to some of your old writings or just write up some of your complaints against Intel here in the forum then I am certain they would be very educational.
Thanks! :)
-
I would dearly love to read some of your criticisms of Intel adding in new instructions to Bill Gates Compatible Computers. Where may I read these scathing criticisms?
There is none, and I don't have a critique on intel. What you and many other people do not understand is that the whole situation with intel is a different one. There is a huge active user community for intel, lots of commercial vendors, lots of software companies developing products, and a customer base that is willing to pay for it. Thus, if you add new instructions, there will be companies picking them up, and users that will pay for them. There will be software that uses them, and there is even the chance that software will slowly migrate away from the old legacy, as they did from BIOS or real-mode.
The situation *here* is a completely different one. There are no new companies developing software for the Amiga, there are no commercial vendors, only legacy applications, and not enough manpower to develop new products. There are no customers paying for them. The whole "amiga market" - if there is such a thing - lives from the legacy CBM left behind. There is no chance that Amiga will migrate away to something more modern. There is already a lot more modern than Amiga, so if you make the cut, make it for real.
Thus, if you are aiming for something new, there are plenty of options for you. Intel and PC is one of them. Hyperion offers other options. AROS is an option, or Linux is an option. But amiga is an old platform, only defined by its legacy.
-
@MattHey
@Thomas Richter
Why do you two keep bringing up these pointless arguments about additional instructions and Mac compatibility? It's obvious that you two have something personal against Gunnar since you continue to bombard this thread with the same non-issues.
This is an FPGA project. If you don't like Gunnar's core, then flash it with one of the Minimig cores and go on your merry way and leave the rest of us alone. Or better yet, do something constructive like contacting the author of WHDLoad and ask him to update WHDLoad with Gunnar's new core in mind. That would solve all of these non-problems you two keep bombarding us with.
-
You mean TG68 core from Tobi, the Minimig core is the chipset, not CPU. The Apollo team is nowhere near anything else but talks when it comes to chipset implimentation, talks about SuperAGA/SAGA when they have not been able to show anything working at all yet.
-
And WHDLoad runs fine on Phoenix - but WHDLoad and the games it supports also run fine on any Amiga with a bit of RAM already, none of the old games have any use for an improved 68k CPU.
-
You mean TG68 core from Tobi, the Minimig core is the chipset, not CPU. The Apollo team is nowhere near anything else but talks when it comes to chipset implimentation, talks about SuperAGA/SAGA when they have not been able to show anything working at all yet.
Matt and Thomas could actually use one of the cores that has been modified to run on the Chameleon. If my memory serves me correctly, it also has a 68k soft CPU in addition to the classic Amiga chipset. Or better yet, they can keep using a real classic Amiga or a UAE variant.....problem solved! Or they could buy a Mining or a Replay board or a Chameleon. Again, problem solved. With all the options out there for running classic systems, the arguments they've been posting here are looking very ridiculous. It's clear they have some personal issue with Gunnar and the technical issues that they keep raising are just smokescreens.
-
And WHDLoad runs fine on Phoenix - but WHDLoad and the games it supports also run fine on any Amiga with a bit of RAM already, none of the old games have any use for an improved 68k CPU.
The old games and applications may have no use for an improved CPU but some of them will run much too fast, so yes, an updated WHDLoad would be nice to have if you want to run your old software at the intended speed on Gunnar's new FPGA.
-
And WHDLoad runs fine on Phoenix - but WHDLoad and the games it supports also run fine on any Amiga with a bit of RAM already, none of the old games have any use for an improved 68k CPU.
I know that you dislike Gunnar
the people interested in it will buy the cards and then we will see what happens. But no whining if you are not part of it :)
-
Funny how anyone who tries to work with Gunnar on this end up having personal issues with him, don't you think? And regarding MacOS, several people have pointed out compatibility issues, but Gunnar says it is all lies. Yet he has yet to prove it by showing MacOS actually running on the core, which should be fairly easy.
I believe this will sort out by itself as people get their hands on the boards and realize how little difference it really makes - you still have a system that needs heaploads of patched, even more old software will not work, you will spend time switching back and forth different accelerators for compatibility, the lack of applications to benefit from Phoenix will be minimal. I kinda suspect that "the enemy" they talk of is Individual Computers.
-
Matt and Thomas could actually use one of the cores that has been modified to run on the Chameleon. If my memory serves me correctly, it also has a 68k soft CPU in addition to the classic Amiga chipset.
No, that would make the whole situation even worse, not better! The point is exactly *not* to segment the platform. How would another core *help* here? Right, not at all, it would make things worse, not better.
Once again, I have absolutely nothing against Gunnar. Why should I? We chat together from time to time, he's doing a great job, and the FPGA project is probably the most sensible project I've seen in years. Just that it doesn't make sense at this point to segment the platform by introducing new incompatibilities. And your answer is to segment it even more, instead of less?
Segmentation of the Amiga market is the single most dominant problem we have here. Or better yet, they can keep using a real classic Amiga or a UAE variant.....problem solved! Or they could buy a Mining or a Replay board or a Chameleon. Again, problem solved.
No, another problem created. Thank you - what's so hard to understand here? Any attempt to define a "new platform" is again the license to fail because it again splits the user basis. Even less users... Thank you.
It's clear they have some personal issue with Gunnar and the technical issues that they keep raising are just smokescreens.
No, not all. You just do not understand the argument. It is not technical at all. I am just saying that introducing new instructions without any requirements analysis is a bad move and pretty premature.
-
Yeah, I am the one who brought up Mac emulation, both because it is an excellent compatibility test, and because it is usefull as old MacOS still has plenty of software that is unmatched on AmigaOS.
As of right now though, more pressing issue is that reaction applications in OS3.9 apparently do not run on Phoenix yet, so no Prefs. I am curious if latest workbench.library (which is 020+) works.
The FPU is (or rather, is planned to be) from what I understand, not compatible with existing FPUs, so no benefit for old FPU intensive software like Lightwave 3D, Imagine etc.
No MMU, just talks about some sort of new MMU that Thomas for sure will fix OS support for with his libraries, same Thomas who is highly critical about a lot of the design decissions and who has clearly stated he is not interested in supporting new instrictions. Old software requiring MMU, from debuggers to VMM and whatever, will not work.
No backend support in any compilers, I am curious what plans OlafS3 plans to support the new instructions etc with AROS/m68k when he has no gcc that support it.
Talks about how Phoenix will be so fast that compatibility with existing software is of no concern, which begs the question - why not just use ARM or some other more relevant architecture instead?
Talks about "killer apps" and "modern browsers", yet boards crippled with only 128MB of RAM, a lot of unecessary incompatibility, shunning off OS developers as well as compilator developers.
Talks about "an enemy", whoever that may be.
Lack of openness, lack of documentation and design route that seems totally ad-hoc, and attitudes that have shunned away other developers for years already. All this is main reason why Natami never really happened in the first place.
Conclusion? Gunnar seems hellbent on creating his own dream CPU, which is fine. Less fine is that he also seems hellbent on luring the entire Amiga 68k community into his proprietary trap. Yeah right, good luck with that.
So, I'd love to see more open and colaborative people to do a more usefull and compatible m68k softcore. Which brings me back to - who is this enemy the Apollo team is talking of?
"Enemy" it was a ironic comment, humor is not your strong side obviously. You do not pay anything, you are not even forced to buy anything and yet are whining all the time.
BTW what are you talking about? He promises to make it compatible so people can develop without using those features, nobody is forced to get into the "trap". As i said it is only for a minority of software. This project is the only realistic option to get 68k development again. Good luck with finding a FPGA development team. Are you able to do it? Then do it. If not stop moaning. And who says I plan to support this new commands with Aros 68k? I do not really care. They would be at best useful for certain purposes. As long Gunnar does not break compatibility I do not care. Regarding WHDLoad even on UAE many games become unplayable because of speed, Wing Commander as a example. If you are only interested in the old hardware why even bother with new hardware. Then you are best with a old A500. Nothing beats the old hardware. New hardware is for new software. 128 MB has (as i explained several times already but you repeat it again and again) has to do with the concept of using off-the-shelve hardware. Guess how much custom hardware would cost and I know what you would then say. It is compromise but you seem not to understand it.
-
And btw, since Thomas is the guy who wrote PhoenixInit which the Phoenix core relies on for running AmigaOS at all, I suspect he may already have a board capable of running the Phoenix core. I know he has stated that he has a Natami developer board too. I would say it well worth to note that a person who has been responsible of updating core components of AmigaOS for a very long period of time, who has been involved in Natami development, who Gunnar himself says will take care of MMU issues in Apollo/Phoenix with his library pack... this same Thomas you claim have personal issues? Oh I don't know, I really just see a guy who keeps calling all critics "liars", but who refuse to disprove the lies, and instead just keeps pushing away those who could actually make his solution profitable for everyone.
-
No, that would make the whole situation even worse, not better! The point is exactly *not* to segment the platform. How would another core *help* here? Right, not at all, it would make things worse, not better.
Once again, I have absolutely nothing against Gunnar. Why should I? We chat together from time to time, he's doing a great job, and the FPGA project is probably the most sensible project I've seen in years. Just that it doesn't make sense at this point to segment the platform by introducing new incompatibilities. And your answer is to segment it even more, instead of less?
Segmentation of the Amiga market is the single most dominant problem we have here. No, another problem created. Thank you - what's so hard to understand here? Any attempt to define a "new platform" is again the license to fail because it again splits the user basis. Even less users... Thank you.
No, not all. You just do not understand the argument. It is not technical at all. I am just saying that introducing new instructions without any requirements analysis is a bad move and pretty premature.
I understand what you write but you are a engineer too (as far as I know) so you understand that engineers have the tendency to overengineer. I myself think the same, concentrate on the important things and then add some things (after knowing what exactly). I do not know how Gunnar defines the requirements but there it is his project so for me the decisive point is does he break compatibility or not. If not it is at least not harmful and as I understand it you have the problems with the way he is adding new instructions but not saying that he breaks with existing software and compilers.
-
No, that would make the whole situation even worse, not better! The point is exactly *not* to segment the platform. How would another core *help* here? Right, not at all, it would make things worse, not better.
Once again, I have absolutely nothing against Gunnar. Why should I? We chat together from time to time, he's doing a great job, and the FPGA project is probably the most sensible project I've seen in years. Just that it doesn't make sense at this point to segment the platform by introducing new incompatibilities. And your answer is to segment it even more, instead of less?
Segmentation of the Amiga market is the single most dominant problem we have here. No, another problem created. Thank you - what's so hard to understand here? Any attempt to define a "new platform" is again the license to fail because it again splits the user basis. Even less users... Thank you.
No, not all. You just do not understand the argument. It is not technical at all. I am just saying that introducing new instructions without any requirements analysis is a bad move and pretty premature.
Segment the platform? You're joking right? You do know that Commodore went bankrupt over 20 years ago so there's no longer a platform or any development for it. And no market either.
Gunnar isn't defining a new platform. He's taken an old one and improved upon it and you seem to have a problem with that. We got that. Now move along and stop bothering the rest of us who would like to see an improved 68K Amiga.
And for someone who has no technical problem with Gunnar's design, you sure do keep pointing out technical issues with Gunnar's work.
If you don't like Gunnar's design, then don't use it! Use a real classic Amiga, UAE, or one of the many other FPGA Amigas. Or maybe you and Matt should join forces and create a design that beats even Gunnar's work. According to you both, you guys know better than the rest of what we want or what we should have.
-
And btw, since Thomas is the guy who wrote PhoenixInit which the Phoenix core relies on for running AmigaOS at all, I suspect he may already have a board capable of running the Phoenix core. I know he has stated that he has a Natami developer board too. I would say it well worth to note that a person who has been responsible of updating core components of AmigaOS for a very long period of time, who has been involved in Natami development, who Gunnar himself says will take care of MMU issues in Apollo/Phoenix with his library pack... this same Thomas you claim have personal issues? Oh I don't know, I really just see a guy who keeps calling all critics "liars", but who refuse to disprove the lies, and instead just keeps pushing away those who could actually make his solution profitable for everyone.
What is your problem? On the holy crusade against Gunnar? You do not need to buy it and you do not need to use it.
-
Segment the platform? You're joking right? You do know that Commodore went bankrupt over 20 years ago so there's no longer a platform or any development for it. And no market either.
Gunnar isn't defining a new platform. He's taken an old one and improved upon it and you seem to have a problem with that. We got that. Now move along and stop bothering the rest of us who would like to see an improved 68K Amiga.
And for someone who has no technical problem with Gunnar's design, you sure do keep pointing out technical issues with Gunnar's work.
If you don't like Gunnar's design, then don't use it! Use a real classic Amiga, UAE, or one of the many other FPGA Amigas. Or maybe you and Matt should join forces and create a design that beats even Gunnar's work. According to you both, you guys know better than the rest of what we want or what we should have.
Thomas has a problem with Gunnar adding commands without exactly defining for what purpose they are needed. For me it is important that existing software works on it. If there are unused commands or not is not interesting to me.
-
Thomas has a problem with Gunnar adding commands without exactly defining for what purpose they are needed. For me it is important that existing software works on it. If there are unused commands or not is not interesting to me.
You and I are in complete agreement here. And the old software won't be making calls to the new instructions anyway, so there should be few if any problems. That's why Gunnar is looking for testers. And if a developer/programmer wants to take advantage of the new instructions, he can. Of course Thomas would not use ANY of the new instructions. He's too worried about segmenting the market and the platform.
And Thomas' call for a requirements analysis is ridiculous. There were no requirements analyses conducted for the original Amiga. The original Amiga wasn't driven by any requirements whatsoever. It was driven by engineers who wanted something better than what was already on the market. And there's no software demand or market today for Amigas to even conduct an analysis in the first place! If everything in the world was driven by requirement analyses we'd all be driving Volkswagen Beetles for cars and using an abacus instead of computers!
-
What is your problem? On the holy crusade against Gunnar? You do not need to buy it and you do not need to use it.
I am not on any crusade against Gunnar, all I did was asking a simple question - will MacOS run under emulation on the Phoenix? That is really a question that can be answered with either "yes" or "no". A whole lot of indicators suggest "no", but Gunnar call those "lies". Promises are worthless in Amigaland, and Natami was a project flooded with promises. And fact is Gunnar has not promised _anything_, but people like you and certain others, keep posting on forums how this and that is promised. I really wish you could stop posting on behalf of people you do not represent. Gunnar has not promised _anything_, and in any case, promises are worthless - only running software has any true value here.
Curious - have you seen AROS running on Phoenix yet?
-
I am not on any crusade against Gunnar, all I did was asking a simple question - will MacOS run under emulation on the Phoenix? That is really a question that can be answered with either "yes" or "no". A whole lot of indicators suggest "no", but Gunnar call those "lies". Promises are worthless in Amigaland, and Natami was a project flooded with promises. And fact is Gunnar has not promised _anything_, but people like you and certain others, keep posting on forums how this and that is promised. I really wish you could stop posting on behalf of people you do not represent. Gunnar has not promised _anything_, and in any case, promises are worthless - only running software has any true value here.
Curious - have you seen AROS running on Phoenix yet?
Here's an idea. Be a beta tester and see for yourself if MacOS will run on it or not!
-
I have been following this thread since it was started!. But now it looks more like a war zone, so why cant we agree on a way forward.
And from there how do we get a working product, something that a user can buy. ?
And right now I really need new amiga hardware most of the time I spend on restoration on commodore/amiga to get them to work so would be extremely good if we as a community can please agree on a way forward to develop new modern amiga hardware.
-
I am not on any crusade against Gunnar, all I did was asking a simple question - will MacOS run under emulation on the Phoenix? That is really a question that can be answered with either "yes" or "no". A whole lot of indicators suggest "no", but Gunnar call those "lies". Promises are worthless in Amigaland, and Natami was a project flooded with promises. And fact is Gunnar has not promised _anything_, but people like you and certain others, keep posting on forums how this and that is promised. I really wish you could stop posting on behalf of people you do not represent. Gunnar has not promised _anything_, and in any case, promises are worthless - only running software has any true value here.
Curious - have you seen AROS running on Phoenix yet?
What are you up now? What is your problem?
-
Here's an idea. Be a beta tester and see for yourself if MacOS will run on it or not!
no I have a better idea for him... stay away from the project and be happy with whatever he uses right now
-
I have been following this thread since it was started!. But now it looks more like a war zone, so why cant we agree on a way forward.
And from there how do we get a working product, something that a user can buy. ?
And right now I really need new amiga hardware most of the time I spend on restoration on commodore/amiga to get them to work so would be extremely good if we as a community can please agree on a way forward to develop new modern amiga hardware.
There's no such thing as the Amiga "community". Amigas are a hobby, not some sort of socialist commune driven by 5-year plans. Gunnar is developing an improved FPGA-based 68K Amiga. Use it or don't use it. If you've been following this thread as closely as you say then you'd know exactly how to obtain a board for testing.
-
no I have a better idea for him... stay away from the project and be happy with whatever he uses right now
+5
I needed to good laugh today. Thanks for providing!
-
As i said it is only for a minority of software. This project is the only realistic option to get 68k development again. Good luck with finding a FPGA development team. Are you able to do it? Then do it. If not stop moaning.
That is exactly the reason to moan. Because unless you speak up then he'll go ahead with his plan rather than creating a fractured development for a minority of software.
It's similar to the land grab that Russia did on Ukraine.
He knows that nobody can compete and so he can force whatever he wants, like Putin.
-
That is exactly the reason to moan. Because unless you speak up then he'll go ahead with his plan rather than creating a fractured development for a minority of software.
It's similar to the land grab that Russia did on Ukraine.
He knows that nobody can compete and so he can force whatever he wants, like Putin.
Ahhhh.....nevermind!
-
Of course Thomas would not use ANY of the new instructions. He's too worried about segmenting the market and the platform.
You again got it wrong. Please read precisely what I have written, and not what you would like to read. I would use new instructions whenever there is a clear advantage, and I would write a dispatcher around it to distinguish between old and new CPU. That happened already multiple times - or how do you think can the mmu.lib support MMUs from the 68851 up to the 68060? All special instructions, but isolated in the code behind an interface. But these are not the instructions we talk about, i.e. special instructions to support special functionality. We are here talking about "bread and butter" instructions that can be easily replaced by instruction sequences of the 68K core, thus there is no advantage. And Thomas' call for a requirements analysis is ridiculous. There were no requirements analyses conducted for the original Amiga.
How do you know? Do think that products are developed by a couple of engineers sitting in the corner, "hey, this looks cool?". Even if it would, back then you could sell a home computer by good hardware. This does not work this time. Times changed, the platform is much smaller. The original Amiga wasn't driven by any requirements whatsoever. It was driven by engineers who wanted something better than what was already on the market.
How do you know? And how come you know "what is better"? I am not so sure about this... And there's no software demand or market today for Amigas to even conduct an analysis in the first place!
So why exactly do we need new instructions then if there is no demand for new software? Exactly... The problem at this point is not "we are missing instructions in the core". If everything in the world was driven by requirement analyses we'd all be driving Volkswagen Beetles for cars and using an abacus instead of computers!
Hardly ever. You probably have never worked in a company?
-
Here's an idea. Be a beta tester and see for yourself if MacOS will run on it or not!
If someone could provide information about the time frame, I may very well do that. However, it seems like the developer boards are already have FPGAs too limited to hold the just now recently decides minimum requirements, so I don't know if it is worth it, looks like waiting for the next batch is better option for me. Currently I'm not home anyways, and wont be for another 5 months.
-
How do you know? Do think that products are developed by a couple of engineers sitting in the corner, "hey, this looks cool?". Even if it would, back then you could sell a home computer by good hardware. This does not work this time. Times changed, the platform is much smaller. How do you know? And how come you know "what is better"? I am not so sure about this... So why exactly do we need new instructions then if there is no demand for new software? Exactly... The problem at this point is not "we are missing instructions in the core".
Hardly ever. You probably have never worked in a company?
Actually yes, that's exactly how the first Apple computers were developed. There was no team of developers and engineers doing any requirements analyses. Same goes for the Amiga. And yes, I've worked for several major companies as well as the government so I'm quite familiar with conducting requirements analyses. Requirements analyses are great for government contracts and the bidding process...horrible for private enterprise and hobbies. And Gunnar isn't developing a product for the masses. Those days are long gone. He's developing a hobby board for Amiga hobbyists. You seem to live in a delusional world where you think there's still an Amiga mass market or one that can be resurrected.
And I can ask you the same question! How do you know what's best for us or for this project? You keep whining about the instruction set. If you don't like the new instructions, stick to the old ones or better yet, just stay away from this project completely and stop confirming your disdain for Gunnar and his work.
I'd much prefer a computer, car, motorcycle, etc.....be developed by engineers who say, wow, this looks cool, let's add this to our project than ANY product developed by bureaucrats who let their designs be driven by a requirements analysis.
-
If someone could provide information about the time frame, I may very well do that. However, it seems like the developer boards are already have FPGAs too limited to hold the just now recently decides minimum requirements, so I don't know if it is worth it, looks like waiting for the next batch is better option for me. Currently I'm not home anyways, and wont be for another 5 months.
There are two links in the very first post of this thread that explain how to obtain a board for testing. One board is for the A600. The other is for an A500/1000/2000. But yes, you are correct. The dev/test boards have a smaller FPGA than the consumer boards that will follow, so it may be better to wait.
-
@ferellsl
so you want to scare one of the main contributors like thor away from the project? are you going to take his place and develop support libraries? and if not, why dont you just hold your mouth or go using os4 or something like that, instead of alienating people here?
-
Actually yes, that's exactly how the first Apple computers were developed. There was no team of developers and engineers doing any requirements analyses. Same goes for the Amiga. And yes, I've worked for several major companies as well as the government so I'm quite familiar with conducting requirements analyses. Requirements analyses are great for government contracts and the bidding process...horrible for private enterprise and hobbies.
And I can ask you the same question! How do you know what's best for us or for this project? You keep whining about the instruction set. If you don't like the new instructions, stick to the old ones or better yet, just stay away from this project completely and stop confirming your disdain for Gunnar and his work.
I have the feeling thanks to Thomas and Matt I will not see this project comes to reality. * sigh * I knew it was to good to be true. Always when something finally new shines up...someone in the community MUST DESTROY it and we will be forever stuck at specs of 68000 @ 7 Mhz 512 KB CHIP RAM.
* sigh * Anything new, anything that takes it a little far away from the 1980's must be destroyed or use the logic then use x86 instead. Sometimes I wonder why not?
-
We are here talking about "bread and butter" instructions that can be easily replaced by instruction sequences of the 68K core, thus there is no advantage.
Yes, I'd have thought the fpga space would have been better used analysing existing instruction sequences at run time and folding them down to faster operations than forcing the apps to be rewritten to make them faster. Essentially what Intel do.
Sure if that has been done and we have an absolutely optimal and 100% compatible FPU and MMU then experiments could be done on moving forward with a new optional next generation ISA. But my guess is that not all options have been exhausted yet. The thrill of being able to say he's added more instructions seems to be too great, but it's actually a failure.
* sigh * Anything new, anything that takes it a little far away from the 1980's must be destroyed or use the logic then use x86 instead. Sometimes I wonder why not?
A x86 or Arm on an accelerator with an open source boot rom that can emulate any type of 68000 and PPC would avoid the problem. Essentially a hardware version of Amithlon, but using real Amiga hardware instead of VGA etc
I won't be buying any hardware that isn't 100% open source. Reverse engineering an fpga in 20 years time won't be fun.
-
I wish the team well, even though Gunnar has for some unknown reason got irritated with the Fpgaarcade team.
I've been pushing back a few fixes for the T68 soft core we currently use. There are potentially a few issues remaining with the 68020 mode,which are problematic to find.
I've developed a daughterboard with a real 68020 (and the rest of the AGA chip set) so I can run the soft cores against the originals and hopefully nail any functional / timing differences.
I am making some progress getting a public SVN mirror up, I expect this to be done in the next couple of weeks which will hopefully pacify some of the more zealous open source people in the community.
Anyhow, for me, 100% functional compatibility is the number one priority, followed by cycle accurate timing in 68000 mode. Then, maximum performance in 68020 mode.
I now have a functional model and microcode dump of a real 68K which is helping design a very lightweight new (open source) core.
One comment I will make (and please don't take offence Phoenix team) is I find it very unlikely you will be able to produce an ASIC. For my day job I design 28nm devices, and the mask costs are high. The cost of respins is high. I'm very open to helping out if you think it is doable.
Anyhow its a small community, lets all work and play together peacefully.
Cheers,
Mike
http://www.fpgaarcade.com
-
What are you up now? What is your problem?
My problem is obviously getting simple answers to simple questions - you are sn AROS/m68k user and distro maintainer - and you are eagerly involved in Apollo/Phoenix - there are plenty of people with Vampire600 and other boards that run Phoenix, you communicate with Gunnar and the Apollo team on their forum, people who should have no problem whatsoever to try out AROS on their hardware - have you ever seen AROS run on the Phoenix core? The answer is either "yes" or "no".
-
@ferellsl
so you want to scare one of the main contributors like thor away from the project? are you going to take his place and develop support libraries? and if not, why dont you just hold your mouth or go using os4 or something like that, instead of alienating people here?
Huh? Not sure what you're referring to here. I don't own or even use OS4, nor have I ever had an exchange with Thor nor discussed anything about developing the support libraries that I'm aware of.
-
@kolla
the answer is so far i have observed, and no, i dont know for sure, that apollo core has not yet run p96, mac os emu or os3.9, because there may be bugs with addressing modes yet to be found. but im pretty sure this will be solved.
-
I wish the team well, even though Gunnar has for some unknown reason got irritated with the Fpgaarcade team.
...
Anyhow its a small community, lets all work and play together peacefully.
Cheers,
Mike
http://www.fpgaarcade.com
Hi Mike,
The issue is very easy to explain.
People told us that you "warned/informed" them that my SAGA chipset
would be based on a copy of a patched Minimig chipset.
-
Matt and Thomas could actually use one of the cores that has been modified to run on the Chameleon. If my memory serves me correctly, it also has a 68k soft CPU in addition to the classic Amiga chipset. Or better yet, they can keep using a real classic Amiga or a UAE variant.....problem solved! Or they could buy a Mining or a Replay board or a Chameleon. Again, problem solved. With all the options out there for running classic systems, the arguments they've been posting here are looking very ridiculous. It's clear they have some personal issue with Gunnar and the technical issues that they keep raising are just smokescreens.
your own words above. not speaking about matt, who anyway helped a lot with a number of amiga projects, but telling one of the few apollo team software contributors, like thor, because he has some valid concerns, he should stay away from the project is everything but constructive.
-
My problem is obviously getting simple answers to simple questions
.
-
Can you read?
This thread is about new developer board to come so that people WILL be able to test the new core.
Is you read this thread then you know the people do NOT have the board yet.
So why do you ask them for testing AROS or MACOS if its clear to the educated reader that without a board they could not have tested it?
-
Matt shoots.... he scores!
... in the wrong goal.
-
Hi Mike,
The issue is very easy to explain.
People told us that you "warned/informed" them that my SAGA chipset
would be based on a copy of a patched Minimig chipset.
Thanks for the response. News to me, I have no idea what you are up to (it being closed source) and hence how could I comment? I think there is some miss-communication here with a 3rd party perhaps.
I have however received "demands" for my code (people assume it is minimig derived) however for use with a Phoenix core, which I politely turned down as it's not released yet.
It is now working pretty much, and will be released.
Best,
Mike
-
Thanks for the response. News to me, I have no idea what you are up to (it being closed source) and hence how could I comment? I think there is some miss-communication here with a 3rd party perhaps.
The owner of the MIST project spoke withus about using SAGA in his board.
He got irritated after you seem to have told him that our code would be an illegal copy of your code.
It was surprising me how room this small scene semm to have for politics.
-
your own words above. not speaking about matt, who anyway helped a lot with a number of amiga projects, but telling one of the few apollo team software contributors, like thor, because he has some valid concerns, he should stay away from the project is everything but constructive.
I still have no idea what you're referring too. I haven't told THOR to stay away. Never mentioned him. I told Matt and THOMAS to stay away if they didn't like this project. It's Gunnar's project and he obviously is getting along quite well in spite of Matt's and Thomas' criticisms. If they don't like the direction that Gunnar is taking his project, they should take it up with Gunnar in offline mode rather than making a spectacle of themselves here. And there are other people who can develop libraries for Gunnar's project, as well as complete alternatives to Gunnar's project such as the Minimig, Chameleon, Mist and Replay boards. No one is forcing anyone to like or adopt or develop for Gunnar's project.
-
Ah yes, I talked to Till about this while I was giving him some T68 updates.
It was a bit of a case of Chinese whispers to be honest, and Till has already apologized to me for any miss-understanding. It would appear Gunnar was a little overly sensitive.
I am continuously surprised at the politics, it all seems a bit unnecessary to be honest.
/Mike
-
I have the feeling thanks to Thomas and Matt I will not see this project comes to reality. * sigh * I knew it was to good to be true.
Actually, I wouldn't be so negative. The boards are produced, and the FPGA core works. Ok, there are bugs, but that is not unexpected. The project requires a bit more professionalism, i.e. once the boards are ready, they should be shipped by a professional vendor in somewhat larger quantities. Always when something finally new shines up...someone in the community MUST DESTROY it and we will be forever stuck at specs of 68000 @ 7 Mhz 512 KB CHIP RAM.
Who does that? If a project is run, do we all have to agree, or is it disallowed to criticize some of its components? Look, I'm all *for* this project, except that I don't quite agree with one minor point. Does that mean that the project will be destroyed? Hardly. It is not even my project. Gunnar has the last say - but that still does not mean that I'm happy with all decisions. Probably I don't have to.
-
I still have no idea what you're referring too. I haven't told THOR to stay away. Never mentioned him. I told Matt and THOMAS to stay away if they didn't like this project. It's Gunnar's project and he obviously is getting along quite well in spite of Matt's and Thomas' criticisms. If they don't like the direction that Gunnar is taking his project, they should take it up with Gunnar in offline mode rather than making a spectacle of themselves here. And there are other people who can develop libraries for Gunnar's project, as well as complete alternatives to Gunnar's project such as the Minimig, Chameleon, Mist and Replay boards. No one is forcing anyone to like or adopt or develop for Gunnar's project.
thor and thomas richter are one and the same person. clear now?
-
I am continuously surprised at the politics, it all seems a bit unnecessary to be honest.
/Mike
so since everybody is a bit sensitive about their projects and surprised about the politics, can this be considered settled in order to start over in mutual respect?
-
so since everybody is a bit sensitive about their projects and surprised about the politics, can this be considered settled in order to start over in mutual respect?
There was never any disrespect from my side.
Absolutely, with communication, tolerance and respect from all sides, this small community would certainly be a happier place.
Mike.
-
thor and thomas richter are one and the same person. clear now?
Wow, so I'm supposed to magically know that? I really don't care if I scare Thomas or Thor or whatever he calls himself, away from this project. With help like his, Gunnar and his project don't need any enemies! Thomas/Thor has been the most vocal detractor of this project via this thread. Scaring him away might be doing everyone a favor!
-
Wow, so I'm supposed to magically know that? I really don't care if I scare Thomas or Thor or whatever he calls himself, away from this project. With help like his, Gunnar and his project don't need any enemies! Thomas/Thor has been the most vocal detractor of this project via this thread. Scaring him away might be doing everyone a favor!
Yes Thomas has been helpful is the past.
But I have to admit that I find this open ranting quite surprising.
If a friend is concerned about some details
then I would have expected some email or phone call to talk about it
not getting such a call but getting started the discussion with public critised is a bit funny.
A lot of misunformation was posted here.
People like Kolla seem totally confused now.
Frankly I can absolutely not follow Thomas logic.
On the one hand side he is afraid that new instructions would kill split the community
and that this would kill AMIGA - on the other hand Thomas did ask for special instruciton to decode JPEG faster.
I really do not get why the one is *evil* but the other one would be a god sent.
-
Wow, so I'm supposed to magically know that?
Guess by reading my readmes? I really don't care if I scare Thomas or Thor or whatever he calls himself,
Actually, I always called myself Thomas Richter. The name of the software product is "THOR Software". Or actually, do you believe "General Motors" is outsourced from the army? (-: away from this project. With help like his, Gunnar and his project don't need any enemies! Thomas/Thor has been the most vocal detractor of this project via this thread. Scaring him away might be doing everyone a favor!
You don't understand, right? If we all jump and dance "happy happy joy joy", there would be no way forward. If something is not right, I raise my voice. But that does not mean that the project is bad - it is not. It is probably the most useful project I have seen in years. If you believe that is "detracting", you probably do not understand how our world moves forward. By discussion and finding the right way by compromizes. This is not my project, and I'm not forcing people on my way - how could I.
Actually, if you really believe I am against this project, why do you think did I write the support library for the current (small) Phoenix core we have? Is that destructive? It is probably not the most importanat task, but may I ask you about your support for the project?
-
Wow, so I'm supposed to magically know that? I really don't care if I scare Thomas or Thor or whatever he calls himself, away from this project. With help like his, Gunnar and his project don't need any enemies! Thomas/Thor has been the most vocal detractor of this project via this thread. Scaring him away might be doing everyone a favor!
you could inform yourself to whom are you talking to and adjust your tone. and now good luck to continue to do your best to drive people who put work on this project apart.
-
On the one hand side he is afraid that new instructions would kill split the community
and that this would kill AMIGA - on the other hand Thomas did ask for special instruciton to decode JPEG faster.
i think thomas is generally sceptical about added instructions at least before a full stable 020 compatibility is achieved. not sure if any of us is totally against it. he just mentioned an example what would be useful from his point of view, if it is unavoidable.
-
i think thomas is generally sceptical about added instructions at least before a full stable 020 compatibility is achieved. not sure if any of us is totally against it. he just mentioned an example what would be useful from his point of view, if it is unavoidable.
but isn't this project in alpha stage anyways? Wouldn't there be multiple core versions that will meet everyone's meet in the long rung? Wouldn't there be issues at first, then as we progress we fix these issues later? Much like PS 4 operating system, linux, windows, etc. All of them have issues at release and get patched as days come by.
ONE OF THE GREATEST pleasure is patching my hardware in my A500 through workbench in my A500 itself. I mean, guys discuss (in civilized way) but whatever concern, issue, etc...aren't all of these will be resolved by downloading a 10 MB compressed zip file and then flashing the card with the new firmware?
I guess the only suggestion I would like to add to biggun if he is willing to listen to me :$ if possible could you add a tiny mini PCI or something that can fit inside the A500 case that allows the person to upgrade the RAM from 128 to say 1 GB or 2 GB RAM.
In the future 128 MB may not be sufficient for latest browsers, youtube, etc. I am hoping with this technology...youtube can be finally achieved in my A500. So I am looking for the forward and would love to have the choice to be able to upgrade the RAM by inserting memory stick into the Vampire 500.
Maybe this RAM extension would be the for the bigger version of Vampire 500 and the budget version is restricted to the limited 128 MB RAM.
I discovered in OS 4.1 that 128 MB is nothing...so from experience I will find 128 MB to be too limiting...especially if I want to do DOSBox, heavy emulation in my A500 etc.
What if the in the future PSX emulator or PS 2 emulator will be ported or N64 will be ported...128 MB is too limiting.
-
lemme comment quickly on subject of "fragmenting the community". because i think it really is an issue.
we have now four main camps everybody knows about and none is particularly happy about the split: amiga, morphos, os4 and aros.
then on amiga we have different 68k cpu versions there is a lot dedicated optimized software versions for. which is pain in the back, because its likely that users are using wrong software versions on wrong cpu and dont know what goes wrong. this is certainly annoying.
then there is aros with all the supported platforms. good thing about is that whatever gets into the repository it is built for all platforms mutually. but all other contributions must be compiled for every platform separately.
now, we have exotic niches like warpos. just as we speak there is an (interesting) project to get warpos working on mediator/sonnet setup i have already pointed to before:
http://eab.abime.net/showthread.php?t=76633&page=3
it is all fine but this is just another incompatible binary platform.
another example is aros68k. although it executes amiga software and aros68k hunk binaries should run natively on amiga except they are linked against aros exclusive libraries, everything else would have to be defined as just another separate platform when putting it on, lets say, aminet.
taking it all into account, even though i am one of very few open aros68k supporters, my concern is to find a lowest common denominator to achieve maximal gain with a minimal effort for all or most these platforms. im not trying to prevent anyone from anything, just placing food for thought in this context.
-
but isn't this project in alpha stage anyways? Wouldn't there be multiple core versions that will meet everyone's meet in the long rung?
i hope the subsequent versions of the core will improve upon each other. what i definitely do not like to see, would be different incompatible versions of the core to address different expectations. some compromise gotta be found.
-
but isn't this project in alpha stage anyways? Wouldn't there be multiple core versions that will meet everyone's meet in the long rung?
Actually, I do not think that this would be a good choice. The argument is again the same as above: If a user would have to decide between software for N different versions, I would expect a lot of trouble. This is very much the same reason why I believe that adding new instructions is not a good choice, at least not without further understanding what is actually needed and what is not.
Look, what I want to avoid is a "software mess" where we have half a dozend of different CPU cores and a user does not know which version of the software to install nowadays. Adding more versions is not helping. Wouldn't there be issues at first, then as we progress we fix these issues later? Much like PS 4 operating system, linux, windows, etc. All of them have issues at release and get patched as days come by.
Oh yes, but these patches do not impact compatibility. Surely enough, the FPGA core will alsa have bugs - this is normal and not unexpected - and these will also be fixed later, also without impacting compatibility.
But what should not happen at this point is to create a "new core" that defines instructions we do not even know about at this point whether they will find applications. ONE OF THE GREATEST pleasure is patching my hardware in my A500 through workbench in my A500 itself. I mean, guys discuss (in civilized way) but whatever concern, issue, etc...aren't all of these will be resolved by downloading a 10 MB compressed zip file and then flashing the card with the new firmware?
Well, yes. If we are talking about bugs, yes. But would you end up with software that says "must flash the core to version 3.4x first, and avoid branch 4A5". Look, with Amiga software (!) we have today the problem that we have (unfortunately) quite a number of extensions and "improvements" that cause problems by mutual incompatibility. Certain programs cannot be used togehter with certain other programs, authors probably did not know better, or decided that an "enhanced interface" would be better, but did not consider side effects.
Now, by moving "software into the hardware", a thing an FPGA core does, we run very much into the danger that the same problem appears again, but on a lower level. Namely, authors (not Gunnar alone) are creating mutual incompatible CPU cores that work almost, but not quite alike. Leading to "unexpected behavior" in some situations. The average user will not be able to resolve such a situation.
Thus, at this point is seems to be very necessary to build on a very stable, and accepted ground. And that is the 68K ISA "as designed by Motorola", and not some "self made" extension. Maybe this extension is even useful, but it is still the wrong start for a project like this. I guess the only suggestion I would like to add to biggun if he is willing to listen to me :$ if possible could you add a tiny mini PCI or something that can fit inside the A500 case that allows the person to upgrade the RAM from 128 to say 1 GB or 2 GB RAM.
Actually, to disappoint you: Gunnar is "only" programming the core. He does not build or design the hardware. So, not the right address. But if you want my two cents: Currently, this would make the project only more expensive and would create more costs, probably also more support costs by folks using incompatible or untested RAM. I would suggest against this, at least now. I discovered in OS 4.1 that 128 MB is nothing...so from experience I will find 128 MB to be too limiting...especially if I want to do DOSBox, heavy emulation in my A500 etc.
Well, but look. Os 4.1 is PPC, which has a lower code density, and which is a more "elaborate" design than AmigaOs. I doubt we will see any browsers soon, or any memory extensive program. Once that happens, be ready for extensions. This is not the final project, it is a start.
-
XboxOwn: hey there, are you trolling too now?
I ask because the RAM limitation with these boards were discussed a couple of months ago, as normal here, it ended up in a hilarious "discussion" about what constitutes a 32bit computer. Hence I find it very amusing that you bring that up again.
-
XboxOwn: hey there, are you trolling too now?
I ask because the RAM limitation with these boards were discussed a couple of months ago, as normal here, it ended up in a hilarious "discussion" about what constitutes a 32bit computer. Hence I find it very amusing that you bring that up again.
Oh God I hope not!! That is not my intention honestly. I will be quite to avoid unintentional trolling
-
There was never any disrespect from my side.
Absolutely, with communication, tolerance and respect from all sides, this small community would certainly be a happier place.
Mike, do you see a need for and would you support a standard's committee? I speak of not just 68k enhancements but also custom chipset enhancements. We recently had a discussion on EAB about custom chipset implementations and enhancements.
http://eab.abime.net/showthread.php?t=77679
Without standards, we are going to end up with many different incompatible enhancements. One standard will gain more and better support from developers. Look at the support of CGFX and AHI which shows how important a standard can be, especially in a small market like the Amiga. Some people have said standards aren't important because the Amiga is on the brink of dying but we have to plan like it will live. New hardware with hardware standards may be what revives it. I tried to document a standard 68k CPU ISA starting back in 2012 but the Amiga was too dead then for most people to worry about. Gunnar would say it is all my fault for rocking the boat of his Apollo ISA standard but I believe his standard is too radical for other 68k FPGA processors to follow. We need more conservative standards which most FPGA hardware and UAE could adopt when there is developer support and software. Custom enhancements could be built on top of the standards. We can't have one person dictating the standards and half a standard is no standard at all. I don't think a standards committee is going to happen without representives from FPGA Arcade and Mist. I would like to hear from compiler developers if possible including Frank Wille and/or Volker Barthelmann (are there any other active Amiga compiler devs?). A-Eon may be interested. A standard's committee would benefit Gunnar as well. Any arguments could be voted on. Anyone should be able to submit ideas and listen in to discussions. I would probably be considered too biased to be chairman which is fine. We can elect someone. I'm not sure what platform would be best. Does anyone like the idea or have any suggestions for improvements?
-
Mike, do you see a need for and would you support a standard's committee?
Matthey,
I totally agree that without some form of standardisation the community will fracture.
From a CPU perspective, I see absolutely no point adding or changing any instructions - I'm focussing on functional and timing accuracy for the 68000, then performance for the 68020+.
Personally, if you are going to mess around with the architecture sufficiently to force a compiler modification, you might as well recompile to something else entirely. ARM or MIPs spring to mind.
For the chipset I have already made a few obvious improvements, such as extending all the DMA address register widths. There is not particularly controversial as there is space to do this in the memory map.
I don't expect software to use it, but if this sort of enhancement could be documented and agreed on, it becomes a possibility.
So yes, happy to be involved.
/Mike
-
Yes Thomas has been helpful is the past.
But I have to admit that I find this open ranting quite surprising.
If a friend is concerned about some details
then I would have expected some email or phone call to talk about it
not getting such a call but getting started the discussion with public critised is a bit funny.
I am totally outside of the project and only know Thomas from postings here on amiga.org, and I am not at all surprised that he has concerns, so how you of all people can be surprised is beyond me. I am quite sure he has raised his concerns to you earlier, as has Matthey. I recall when Matthey released his 68k roadmap and found it an odd thing to do, but now I totally understand where it came from.
A lot of misunformation was posted here.
People like Kolla seem totally confused now.
Actually I am not confused at all, I am just disappointed by so many factors of this project. It's kinda like Natami all over again.
Frankly I can absolutely not follow Thomas logic.
On the one hand side he is afraid that new instructions would kill split the community
and that this would kill AMIGA - on the other hand Thomas did ask for special instruciton to decode JPEG faster.
I really do not get why the one is *evil* but the other one would be a god sent.
Look, I am not a hardware engineer or software developer, but even I understand what he says - which is to keep the CPU clean and compatible, and put all "extra fun" in dedicated units.
I am all for MikeJ's approach - make damn sure you have pretty much 100% working and compatible 68020 core, _then_ tweak it for speed, piece by piece, so if something breaks, it is easy to pinpoint why, and fix/backtrack. When this stabilizes, by all means - make coprocessors all you like, but keep the 68020 CPU core untouched and as clean as possible. What you seem to be doing is tweaking the CPU before almost before anything at all is running, which in my view will result in a whole lot of unecessary bugs all over the place. But maybe I am jusy stupid and you really are a genious. Time will show.
-
I discovered in OS 4.1 that 128 MB is nothing...
i see everybody is buying os4.1fe to try it out on uae and discovers that it is about unusable. funny. the same people could get aros68k, which is for free, can use almost unlimited amount of ram and unlimited screen resolution under uae, and discover, that 128mb ram is already plenty with the same or better features as are impossible to reach on os4. css web browsing to name just an example.
in short: as thor said above, the 68k code is more efficient, at least when it comes to memory usage.
-
you could inform yourself to whom are you talking to and adjust your tone. and now good luck to continue to do your best to drive people who put work on this project apart.
So I'm just supposed to magically make the connection that two different names on two different forums are the same person? That's as ridiculous as demanding MacOS compatibility or the outright rejection of Gunnar's project because of new CPU instructions.
If people working on Gunnar's project are so unprofessional as to quit like cry-babies because of MY posts, then Gunnar and the rest of us really are better off without them!
Even Gunnar finds Thor/Thomas' comments and logic puzzling....not to mention that he's making an open spectacle of himself because of his resistance to additional CPU instructions. This situation is no different than using AltiVec extensions on a PPC CPU. If you don't want to use AltiVec, then don't use it. Same goes for SSE instructions on Intel/AMD. But I don't know of ANY programmers who set out to cripple their code.......
-
Oh God I hope not!! That is not my intention honestly. I will be quite to avoid unintentional trolling
Allright :) I was very tempted to to answer you that you sadly have to wait for Gunnar's promised 64bit addressing mode, which btw is something he may do on a whim any day now, so that you can even have 4GB and beyond. But that would have been trollish of me :)
-
If people working on Gunnar's project are so unprofessional as to quit like cry-babies because of MY posts, then Gunnar and the rest of us really are better off without them!
Have you printed out his avatar photo and framed it above your bed already? :)
-
Matthey: I would contact Linux/m68k developers, gcc/glibc developers and NetBSD developers and ask if they would be interested in participating.
-
My problem is obviously getting simple answers to simple questions - you are sn AROS/m68k user and distro maintainer - and you are eagerly involved in Apollo/Phoenix - there are plenty of people with Vampire600 and other boards that run Phoenix, you communicate with Gunnar and the Apollo team on their forum, people who should have no problem whatsoever to try out AROS on their hardware - have you ever seen AROS run on the Phoenix core? The answer is either "yes" or "no".
No not yet
And now?
What will you create by this?
-
@ferellsl
so you want to scare one of the main contributors like thor away from the project? are you going to take his place and develop support libraries? and if not, why dont you just hold your mouth or go using os4 or something like that, instead of alienating people here?
Certain people are doing their political agenda here
It is Gunnars time invested in the project not Kollas or any other
I see no reason to mistrust Gunnar there and the nice thing about FPGA is you can change it. So I do not understand what this discussion is about. Matt and Kolla can do a new FPGA core themselves if they think they are better. Simply as that.
-
I don't see what the problem is. Don't we already have different executables for different CPUS ?
Didn't read the whole thread so sorry if this was said already...
-
Mike, do you see a need for and would you support a standard's committee? I speak of not just 68k enhancements but also custom chipset enhancements. We recently had a discussion on EAB about custom chipset implementations and enhancements.
http://eab.abime.net/showthread.php?t=77679
Without standards, we are going to end up with many different incompatible enhancements. One standard will gain more and better support from developers. Look at the support of CGFX and AHI which shows how important a standard can be, especially in a small market like the Amiga. Some people have said standards aren't important because the Amiga is on the brink of dying but we have to plan like it will live. New hardware with hardware standards may be what revives it. I tried to document a standard 68k CPU ISA starting back in 2012 but the Amiga was too dead then for most people to worry about. Gunnar would say it is all my fault for rocking the boat of his Apollo ISA standard but I believe his standard is too radical for other 68k FPGA processors to follow. We need more conservative standards which most FPGA hardware and UAE could adopt when there is developer support and software. Custom enhancements could be built on top of the standards. We can't have one person dictating the standards and half a standard is no standard at all. I don't think a standards committee is going to happen without representives from FPGA Arcade and Mist. I would like to hear from compiler developers if possible including Frank Wille and/or Volker Barthelmann (are there any other active Amiga compiler devs?). A-Eon may be interested. A standard's committee would benefit Gunnar as well. Any arguments could be voted on. Anyone should be able to submit ideas and listen in to discussions. I would probably be considered too biased to be chairman which is fine. We can elect someone. I'm not sure what platform would be best. Does anyone like the idea or have any suggestions for improvements?
The standard is the existing hardware (processor+chipset) and the rest is done by the OS (perhaps with special optimized libraries)
-
No not yet
And now?
What will you create by this?
Allright, thank you for answering. I was just curious and I'm adding this to the pool of information about this project. I find it interesting that noone has bothered to test out AROS/m68k on Vampire600 yet.
-
Allright, thank you for answering. I was just curious and I'm adding this to the pool of information about this project. I find it interesting that noone has bothered to test out AROS/m68k on Vampire600 yet.
*sigh*
then have nice dreams
-
I don't see what the problem is. Don't we already have different executables for different CPUS ?
Yes we do, and none of them will be optimized for Phoenix in any shape or form. There is tons of software optimized for 020+FPU and they will not work. There's also plenty of software optimized for 040 and 060 that also will not work. Unless you have the sources and the know-how to optmize for Phoenix using assembler, you are out of luck regarding the speed "advertized".
-
I find it interesting that noone has bothered to test out AROS/m68k on Vampire600 yet.
they did before the core gained 020 extensions. which didnt run, and therefore led to discovery that aros68k, even though compiled for plain 68000 target, had an asm inline containing an 020 instruction by oversight. toni found and fixed it. i think this is already some positive outcome of collaboration on the aros68k/apollo front.
i dont know though why they didnt come any further with it, or if they did, why the did not communicate it.
-
To Thomas,
Lets look at some numbers
Phoenix today can reach over 300 Mips - this means Phoenix is like 20-30 times faster than todays ACA cards.
We see on the horizon the next gen FPGAs.
This means we can have a future roadmap where we know we can create cards with over 1000 Mips.
The performance difference between Phoenix and old 68030 cards is so ridicolous
that I think the wish to run future killer applications on both platforms is pointless.
Nice news ... If you , Majsta Thor and any others contributing can make a card that would be just 020 combatible (fpu or no fpu) and beat 060/100 Mhz by a margin of even 50 % AND add any kind of RTG to it as well (800x600x24bit would be GREAT) you would have best product on the retro market.Shapeshifter can run on 020 without FPU and with RTG it flies and playing around with old Macs I'm pretty sure System 7.5.3 (which is freely available from apple now) would work (It was already PPC there but 68k compatible as well) and most things could be made to work.
Was little sceptic about this but seeing A600 running ADoom in 24+ FPS full screen in ECS HAM mode (!) and verifying that from more than 3 people seems to be proof enough for me.
Don't overestimate end-user wishes :)
-
I totally agree that without some form of standardisation the community will fracture.
I think the majority of us should be able to see this after what has happened on the Amiga and in this thread.
From a CPU perspective, I see absolutely no point adding or changing any instructions - I'm focussing on functional and timing accuracy for the 68000, then performance for the 68020+.
Personally, if you are going to mess around with the architecture sufficiently to force a compiler modification, you might as well recompile to something else entirely. ARM or MIPs spring to mind.
There is probably a minimal benefit for a 68k CPU enhancement for the FPGA Arcade or any other hardware focused on emulation accuracy right now. There are customers who want higher performance CPU cores and will want to run software compiled for higher performance cores like Apollo/Phoenix though. You can offer a retro compatible core without enhancements and a high performance core with enhancements provided the standard was not too difficult. ColdFire compatibility should be appealing for Atari Firebee users, program sizes could be reduced by 5%-15% to better fit the limited storage space and some FPGA Arcades may even sell for embedded purposes (the Raspberry Pi has sold many units for embedded purposes although it is cheaper and smaller). MIPS programs would be approaching twice the size of 68k+CF programs and they need that much more caches too. Thumb 2 is competive in code density with the 68k but a 68k+CF would be better and can have better single core and memory performance. Most of the CPU evaluation and testing would happen on more performance oriented hardware. Custom chipset enhancements are obviously higher priority.
For the chipset I have already made a few obvious improvements, such as extending all the DMA address register widths. There is not particularly controversial as there is space to do this in the memory map.
I don't expect software to use it, but if this sort of enhancement could be documented and agreed on, it becomes a possibility.
Documenting and making public the changes would be a good start. The custom chips are not my strong point but I would think RTG/chunky custom chip enhancements and maybe some improvement in the audio department would be wanted by most FPGA projects.
Matthey: I would contact Linux/m68k developers, gcc/glibc developers and NetBSD developers and ask if they would be interested in participating.
There are developers assigned to the 68k GCC backend but what they do is usually minimal maintenance. It wouldn't hurt to try inviting them to participate. As far as BSD/Linux 68k developers, there aren't very many active 68k developers and most need an MMU (ThoR and Frank Wille could give some insight if they were interested).
The standard is the existing hardware (processor+chipset) and the rest is done by the OS (perhaps with special optimized libraries)
Is 68020+AGA enough for everyone? These are well defined and it's not a bad standard but is that enough forever? If we want more, then we should create new standards.
-
Allright :) I was very tempted to to answer you that you sadly have to wait for Gunnar's promised 64bit addressing mode, which btw is something he may do on a whim any day now, so that you can even have 4GB and beyond. But that would have been trollish of me :)
I was not aware of that fact. Thanks for the great news regardless :)
-
I was not aware of that fact. Thanks for the great news regardless :)
I hope you are as tongue-in-cheek as I am now :)
-
I hope you are as tongue-in-cheek as I am now :)
Uuh........:angry:...............okkaaay?.....uuuh........
-
Oh no! You see now how fast random statements become "facts" and "promises"?
Ask OlafS3 about facts regarding 64bit addressing, he was very well informed when it came up.
-
There are developers assigned to the 68k GCC backend but what they do is usually minimal maintenance. It wouldn't hurt to try inviting them to participate. As far as BSD/Linux 68k developers, there aren't very many active 68k developers and most need an MMU (ThoR and Frank Wille could give some insight if they were interested).
Yeah, that's kinda why I would like some BSD and Linux kernel developers on board, to have more voices to chime in regarding MMU implementation. uCLinux does not rely on the MMU.
Is 68020+AGA enough for everyone? These are well defined and it's not a bad standard but is that enough forever? If we want more, then we should create new standards.
Nothing is ever enough for everyone, I'd love FPU and MMU as well. AGA that is faster and can do higher resolutions would be awesome. To be honest, I don't care about games, I just want to animate with DPaint and various other software again with as many limitations as possible squashed, such as ammount of chipram, speed of chipram access, rendering speed etc.
-
There are developers assigned to the 68k GCC backend but what they do is usually minimal maintenance. It wouldn't hurt to try inviting them to participate. As far as BSD/Linux 68k developers, there aren't very many active 68k developers and most need an MMU (ThoR and Frank Wille could give some insight if they were interested).
radoslaw k. (strim) is netbsd developer and maintainer for amiga. he is a talented driver coder, provided wide pool of support for specific amiga extensions including mediator boards and zorro cards. would be worth to attract, but
1. he is critical about closed source, he mentioned it to me in context of apollo core.
2. he has other own hardware projects and in particular a concurrent sonnet warpos driver project i mentioned above.
-
Many of you folks have many expectations. As long as it's totally 020 compatible and fast, who really cares! Everyone talks future, let it evolve first. Would really like to run anything on Amiga first before any other, after that it's cake.
Chris
-
I would like to have an 060 speed expansion this year. In another year or two the 300mhz 060 speed expansion.
There should be a compatible version and also a fast version. Because even a small group of people are going to have disagreements.
-
Have you printed out his avatar photo and framed it above your bed already? :)
No, but I have yours mounted on my dart board and it's full of holes already.
-
Personally, if you are going to mess around with the architecture sufficiently to force a compiler modification, you might as well recompile to something else entirely. ARM or MIPs spring to mind.
I agree. The only reason for adding extra instructions is so you can put something on your CV and to have something to talk about over a beer.
In the case of the FPU, the only way it's faster is to make it less accurate. If accuracy is not important then it's possible to make all FPU operations take no time at all, just make them all return 0. It would be just as useful for running all your old FPU apps.
I don't have any doubts over technical prowess but in terms of direction he needs to know that diverging from the original specifications is not what anyone really wants. You can probably find some people that say they are happy with it, but they are probably making assumptions over what they will receive that nobody is even attempting to achieve.
100% 68060 compatible CPU+FPU+MMU is the only "compromise" that I'm happy with, Motorola took things out and people have spent decades making sure the software runs. We shouldn't have to start that process again just yet.
Even if you attempt to make something 100% compatible you will fail, if you start out aiming lower than 100% then when you fail it gets real ugly.
-
And WHDLoad runs fine on Phoenix - but WHDLoad and the games it supports also run fine on any Amiga with a bit of RAM already, none of the old games have any use for an improved 68k CPU.
All my games have use for an improved 680x0 CPU.
Even my old A500 games required a 68020+ after circa 1990. 25Mhz 68030 accelerators were sold everywhere for A500 in 1990s. They had 68020 and 68030 accelerators in 1980s too.
All my games have use for a faster CPU.
All my games have use for additional instructions.
All my games have use for more RAM.
-
All my games have use for additional instructions.
I am assuming you haven't written self aware games that rewrite themselves and you mean that YOU have use for additional instructions(*) in further updates.
Assume you're dead and nobody is going to bother updating your games, do you still think they have use for additional instructions(*)?
(*) additional instructions refers to ones that gunnar is going to add that will hurt compatibility, not ones that Motorola already added and we've dealt with those compatibility issues already.
-
If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.
What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?
No.
Coldfire was designed on purpose to be permanently incompatible with all previous processors.
It was very deviously and fiendishly designed. Someone paid someone a LOT of money as a bribe to cook up this wacked out mysteriously hyper-incompatible cpu.
When Matt et. al. talk about coldfire compatibilty they are referring to adding in a few new instructions that can be 100% compatible. But you need to understand that some coldfire instructions are just completely ridiculously incompatible.
If you want to run Coldfire code on a non coldfire cpu then you must use emulation.
-
I really dont see a big problem here. Adding new instructions will not hurt compatibility of existing software. Future software can make use of them but the programmer can also decide to leave them out and use standard instructions. I see it as added value and it can be used to show of the power of the new core and thus attract more users. It wasnt an uncommon thing in Amiga land to have different executables for different processors anyway. I dont expect to see that much new software anyway...
-
Coldfire was designed on purpose to be permanently incompatible with all previous processors.
It was very deviously and fiendishly designed. Someone paid someone a LOT of money as a bribe to cook up this wacked out mysteriously hyper-incompatible cpu.
Hardly. Nobody was bribed for anything - what for? Motorola made a clear statement on their future product development. PPC for desktop, coldfire for embedded. Of course you don't want one product to damage or intrude the market for another, but that does not require bribary, it is a business decision. Coldfire was designed to be as minimal as possible and as cheap as possible, and that means that a lot of legacy baggadge had been removed. That they did not want to invest more money into the 68K as desktop processor was only logical after their largest user (Apple) jumped on the PPC stream.
Hence, there is no conspiracy here. It is just a business decision. In retrospect, probably not a very smart decision given the limited performance and scalability of risk processors, but back then, who could know that? All the signs were that risk would be the future, and to invest the limited resources in this branch would make sense.
-
Adding new instructions will not hurt compatibility of existing software.
Any opcode that would cause an exception on a real 680x0 cpu can be used by software as a virtual opcode. LINEA & LINEF were officially available for that, but it's certainly possible that a piece of software could rely on any exception. The MMU & FPU that is proposed is certainly incompatible.
I don't believe compatibility with existing software is high up on his priority list. If there is any choice of performance vs compatibility, then I expect old software to stop working to allow the handful of new apps to run quicker. I don't expect that he's running every single piece of software ever written to check that his changes aren't causing any problems either.
-
Any opcode that would cause an exception on a real 680x0 cpu can be used by software as a virtual opcode. LINEA & LINEF were officially available for that, but it's certainly possible that a piece of software could rely on any exception. The MMU & FPU that is proposed is certainly incompatible.
Actually, it is a bit more complicated. Line-A is certainly not available for new opcodes as this line is taken, both by MacOs (operating system traps) and also by Atari TOS (the blitter).
The F-Space is partially available. Motorola has the standard 68882 FPU mapped there, and the MMU, and some extended instructions of the 68060/040 map here.
Besides that, some new functions can at least cause problems, e.g. a new set of data registers or a new address register. Problem is that these are not saved and restored by the exec scheduler. Thus, the scheduler would need to be patched. But then, a couple of utilities depend on the stack frame of the scheduler, thus you can either continue to use these programs and not make use of the new registers, or use the registers and get rid of the programs.
Actually, I personally would rather get rid of the extra registers as I consider the Amiga "market" too small for such an experiment.
Anyhow, all these are engineering arguments, but my central point is not even related to engineering. I don't want to repeat this all over again.
-
68k -> coldfire may be useful : http://www.microapl.co.uk/Porting/ColdFire/pacf_download.html
One also needs to consider a universal assembler language for any CPU this generation or the next.
20 years ago it was, 68k, then PPC, now mips is cheap and popular what is next 50 years ?
Virtual ASM + virtual CHIPSET
For example use IOMMU technology (graphics address remapping)
port this to the current generation cheapest CPU + GPU combo and BINGO - Amiga runs.
CPU + GPU = AmiChip
Open source fully documented registers, one could just learn ASM+GPU coding on any device. Hardware does not matter.
We have bigger problems than worrying about which hardware to use. want to use 68k - great, x86 great, DSP great - whatever floats your boat.
It should be all AmiChip I, II, III compatible.
However, due to the urgency of having apps and games ASAP I would favour a single GFX mode eg 1024x768 common monitor resolution at 24 bits colour.
A clean slate so to speak.
We can develop apps and games for this single mode, slowly testing Amiga compatibility later in stages.
-
So you don't need an operating system?
-
So you don't need an operating system?
Technically you do not need an operating system. Dos, windows, Linux, mac, amigaos, basic, etc are all luxury. You can have a computer without os period. NES and Snes are two great examples where OS does not exist and Games developed directly at machine language.
-
Phoenix does support _ALL_ address modes of the 68K family
this includes _ALL_ address modes of 68020 to 68060.
Phoenix is designed to provide full compatibility to existing software. We are not aware of any incompatibilities.
http://www.apollo-core.com/knowledge.php?b=2¬e=2861&z=fwkq39
What does this imply? I presume FPU and MMU to not be in that soup, so compatibility is against 68EC030-EC060?
-
Any opcode that would cause an exception on a real 680x0 cpu can be used by software as a virtual opcode. LINEA & LINEF were officially available for that, but it's certainly possible that a piece of software could rely on any exception.
A-line is documented as user reserved. IMO, gated or switched on A-line instructions would be under user control so acceptable.
An unimplemented A-line exception corresponds to vector number 10 and occurs when an instruction word pattern begins (bits 15%&$#?@!%&$#?@!%&$#?@!8211;12) with $A. The A-line opcodes are user-reserved and Motorola will not use any A-line instructions to extend the instruction set of any of Motorola%&$#?@!%&$#?@!%&$#?@!8217;s processors. A stack frame of format 0 is generated when this exception is reported. The stacked PC points to the logical address of the A-line instruction word.
Where did you get your information for F-line? Some operating systems did use F-line for traps but I have not seen documentation designating F-line as user reserved. Motorola's own MMU and FPU were incompatible with some software.
An unimplemented F-line exception occurs when an instruction word pattern begins (bits 15%&$#?@!%&$#?@!%&$#?@!8211;12) with $F, the MC68060 does not recognize it as a valid F-line instruction (e.g., PTEST), and the processor does not recognize it as a floating-point MC68881 instruction. This exception corresponds to vector number 11 and shares this vector with the floating-point unimplemented instruction and the floating-point disabled exceptions. A stack frame of type 0 is generated by this exception. The stacked PC points to the logical address of the F-line word.
The MMU & FPU that is proposed is certainly incompatible.
I am not aware of any interface to the MMU. It's possible the interface disappears completely or an unused coprocessor ID is used for maximum compatibility. Compatibility with a particular 68k could be provided by trapping. The FPU could be moved to another coID also but that wouldn't be very convenient when executing FPU code. The FPU changes I proposed are only incompatible with BCD floating point which I am not aware of any program on the Amiga which used it and it was trapped already on the 68040. It's in the same category as the 68020 only CALLM/RTM. Jim Drew said the MacOS does use this support but it should be possible to make it faster by working around it considering it is trapped on the 68040-68060 anyway. Other workarounds are already necessary with the "incompatible" 68060 FPU which has a mostly incompatible stack frame size causing crashes on initialization in most FPU software. This is patched in the AmigaOS and probably MacOS where detected. There could be some incompatibility if enabling 8 more FPU registers but then the performance could be up to twice as fast if FPU instruction results are not available to the next instruction. An SIMD unit would also have the same incompatibility when enabled but could provide several times the performance in some cases. The performance gains are big enough to warrant these additions, IMO. I believe the performance gain from more CPU integer registers would be significantly smaller and the potential for compatibility problems greater once the new registers were enabled.
http://www.apollo-core.com/knowledge.php?b=2¬e=2861&z=fwkq39
What does this imply? I presume FPU and MMU to not be in that soup, so compatibility is against 68EC030-EC060?
Addressing modes should work with coprocessors. The 68k/6888x from the beginning has done decoding and EA calculation in the integer units before passing the instruction to the coprocessor for completion. The Apollo core was going to have a fully pipelined FPU and I don't know what affect this would have.
-
Technically you do not need an operating system. Dos, windows, Linux, mac, amigaos, basic, etc are all luxury. You can have a computer without os period. NES and Snes are two great examples where OS does not exist and Games developed directly at machine language.
Of course, but what I responded to also mentioned "apps", applications too do not technically need an OS, but a functional OS is damn usefull for anyone creating or using an application.
-
All my games have use for an improved 680x0 CPU.
Even my old A500 games required a 68020+ after circa 1990. 25Mhz 68030 accelerators were sold everywhere for A500 in 1990s. They had 68020 and 68030 accelerators in 1980s too.
All my games have use for a faster CPU.
All my games have use for additional instructions.
All my games have use for more RAM.
Maybe you targeted the wrong platform? :)
-
A-line is documented as user reserved. IMO, gated or switched on A-line instructions would be under user control so acceptable.
Reserved for the user, meaning the application and not the CPU.
Where did you get your information for F-line? Some operating systems did use F-line for traps but I have not seen documentation designating F-line as user reserved. Motorola's own MMU and FPU were incompatible with some software.
Documentation is irrelevant, only how the chips behave is relevant if you want to be compatible. Past incompatibilities can't be helped, only future ones. I'd pick whatever the 68060 + FPU + MMU does as anything that needs to run fast will have been written for it & a lot of the work to make sure everything else can run on 68060 has been pretty much done.
-
100% 68060 compatible CPU+FPU+MMU is the only "compromise" that I'm happy with, Motorola took things out and people have spent decades making sure the software runs. We shouldn't have to start that process again just yet.
Something new doesn't have to be 100% m68060 compatible in the sense that it could appear to the OS and software as 100% m68060 compatible, but the instructions in the m68060 which are unimplemented can be implemented in the new processor core. No sense running a trap call for emulated instructions.
-
I am not aware of any interface to the MMU. It's possible the interface disappears completely or an unused coprocessor ID is used for maximum compatibility.
I am not aware that there are currently MMU-activites for the Phoenix/Apollo core... On the 68K, there is a coprocessor ID reserved for it, but in reality, the MMU instructions differ already between 68020/68030 and the 68040/68060 substantially. Actually, given the small number of programs that really depend on the hardware interface, it is less a problem to create a new interface here. The FPU is more often used at instruction level, hence, compatibility on instruction level is much more important here. Compatibility with a particular 68k could be provided by trapping.
Partially. For the FPU, certainly. For the MMU: This is not sufficient, because the MMU does more than execute instructions and update registers. If you would want to emulate the MMU at instruction level, you would also need to emulate the table-walk of the MMU. Actually, concerning the FPU: Additional FPU registers are again problematic, again due to the exec scheduler. I believe it would be wiser to have the second set of FPU registers, or a specialized vector-FPU available under an additional coprocessor ID. The standard scalar FPU would preserve the legacy interface, and could be saved and restored by exec. Hence, programs and tools for applications that only use the scalar FPU could remain unchanged. If you need more speed, you would engange the "vector FPU" under a new coprocessor ID, and an updated exec scheduler would save and restore its registers. Hence, the incompatibility would only involve programs that actually use the new FPU, and not all programs. There could be some incompatibility if enabling 8 more FPU registers but then the performance could be up to twice as fast if FPU instruction results are not available to the next instruction. An SIMD unit would also have the same incompatibility when enabled but could provide several times the performance in some cases. The performance gains are big enough to warrant these additions, IMO.
See above. I would advice against extending the scalar FPU. If you need more registers, or vector instructions, enable an extended vectorial FPU. This would allow exec to continue using its legacy stack frame if the vectorial FPU is not used, and hence incompatibilities could be minimized. Addressing modes should work with coprocessors. The 68k/6888x from the beginning has done decoding and EA calculation in the integer units before passing the instruction to the coprocessor for completion. The Apollo core was going to have a fully pipelined FPU and I don't know what affect this would have.
Well, for the FPU yes. For the MMU, this was only the case up to the 68030. The MMU interface changed substantially in the 68040, and there is no longer any flexibility in the supported addressing modes.
-
Actually, given the small number of programs that really depend on the hardware interface, it is less a problem to create a new interface here.
As long as you don't care about running old software, but as soon as you open up that for debate then why worry about any old software. Just stick a fast x86 in there and run an emulator.
-
I am not aware that there are currently MMU-activites for the Phoenix/Apollo core... On the 68K, there is a coprocessor ID reserved for it, but in reality, the MMU instructions differ already between 68020/68030 and the 68040/68060 substantially. Actually, given the small number of programs that really depend on the hardware interface, it is less a problem to create a new interface here. The FPU is more often used at instruction level, hence, compatibility on instruction level is much more important here. Partially. For the FPU, certainly. For the MMU: This is not sufficient, because the MMU does more than execute instructions and update registers. If you would want to emulate the MMU at instruction level, you would also need to emulate the table-walk of the MMU.
The FPGA Arcade and Mist have small enough memory sizes to get away with a 68040/68060 MMU. If Gunnar is not interested in a 68040/68060 MMU compatibility layer for his Apollo core then there isn't much reason to create a standard unless other FPGA Amiga hardware is introduced with more memory. Maybe a better way to query what hardware is available would be useful though.
Actually, concerning the FPU: Additional FPU registers are again problematic, again due to the exec scheduler. I believe it would be wiser to have the second set of FPU registers, or a specialized vector-FPU available under an additional coprocessor ID. The standard scalar FPU would preserve the legacy interface, and could be saved and restored by exec. Hence, programs and tools for applications that only use the scalar FPU could remain unchanged. If you need more speed, you would engange the "vector FPU" under a new coprocessor ID, and an updated exec scheduler would save and restore its registers. Hence, the incompatibility would only involve programs that actually use the new FPU, and not all programs. See above. I would advice against extending the scalar FPU. If you need more registers, or vector instructions, enable an extended vectorial FPU. This would allow exec to continue using its legacy stack frame if the vectorial FPU is not used, and hence incompatibilities could be minimized.
This is a good idea in theory but there are problems. A new SIMD/vector unit in an FPGA may only support integer operations because of the cost of even single precision floating point. There are several choices:
1) 8 register FPU with integer only SIMD = slow fp performance
2) 8 register FPU and wait for an SIMD with single precision fp = slow fp performance now
3) No FPU with SIMD supporting single precision fp = poor fp compatibility
4) 16 register FPU with integer only SIMD = average fp performance
5) 16 registers FPU and wait for single precision SIMD = average fp performance now
I thought 8 FPU registers was adequate when Gunnar wanted 16. I encoded it and found that it works out very well (unlike adding integer registers). The registers are orthogonal except for FMOVEM but the upper 8 FPU registers can and should be scratch registers, IMO. The 68k FPU would be much more efficient with more scratch registers (the cost of saving and restoring extended precision FPU registers is very expensive). Making all 8 new FPU registers scratch registers would cut the number of FPU register saves and restores in half or more, would be very efficient for passing arguments to functions in FPU registers which do not need to be preserved and fp instructions can be interleaved which could up to double performance when the result of one instruction can't be used in the next instruction. This could allow reasonable performance of wide operations in a slow FPGA and/or a 2nd FPU superscalar unit. Keeping the FPU extended precision makes more sense with 16 registers because of the register argument passing and reduced register saves and restores. Most compilers waste the 68k FPU extended precision by passing arguments as 64 bits on the stack which is easy and efficient to improve with 16 FPU registers and a new ABI. Which do you think would cause the least incompatibility?
A) adding 8 FPU registers and patching the exec scheduler
B) reducing FPU precision from 80 bits to 64 bits
I would choose A) above. Most FPU code does not rely on the extended precision but I know that several 68060FPSP algorithms would need fixing (if possible) or new algorithms. The performance advantage of a 64 bit FPU is significantly reduced when extra instructions are needed to retain maximum precision which are not needed with extended precision. I agree that the extra few bits of precision can be very useful too.
Compatibility is very important given the current state of the 68k Amiga but we need to increase performance and plan for the future also. Adding 8 FPU registers looks like a tremendous opportunity to me even if it adds some incompatibility when the extra FPU registers are used.
-
So if I understood this post :
1 + 2 always equals 2 + 1 and nothing else.
The instruction set of a cpu is the set of its users.
A quantum 680x0 would be a heresy unless its clock frequency is less than or equal to 7 MHz.
I have a migraine.
-
Compatibility is very important given the current state of the 68k Amiga but we need to increase performance and plan for the future also.
The only reason to rush through suggestions for new instructions is to stamp your name on it for kudos. I'd rather buy something that can run all software at 68060 66mhz speeds than something that may run at 0mhz or 300mhz depending on the software (if it isn't compatible then it's 0mhz).
We can go out and buy 030 cards relatively cheap, it's the top end 060 cards that are in demand and that is where the biggest market is.
But compatibility doesn't appear to be very important to this project.
-
As long as you don't care about running old software, but as soon as you open up that for debate then why worry about any old software. Just stick a fast x86 in there and run an emulator.
Sorry, I don't get your argument. There are already two incompatible(!) MMU models, the 68030/68851 and the 68040/68060. Even within the same family, subtile differences exist, so a single program cannot depend on a single set of instructions already. Note again that the instructions and the programming logic is already different from MMU to MMU.
Thus, MMU is "system programming" and "supervisor instruction set", whereas the above integer instructions are "user programming" and "user instruction set". A user program has no reason to access the MMU in first place. That's the job of the Os, or in case of the Amiga, of the CPU support library.
The supervisor programming logic is already different from family to family in the 68K land, so nothing new here. The user-land programming did not, or rather, only a single cut was introduced with the 68020.
-
This is a good idea in theory but there are problems. A new SIMD/vector unit in an FPGA may only support integer operations because of the cost of even single precision floating point.
Why is there a difference between eight additional registers in a single FPU and eight additional registers in a dedicated FPU? I don't see one. To save the first set, use FMOVEM with the co-processor ID of the 68881. To save the second set, use the coprocessor ID of the second FPU. Even better, programs only using the first FPU would only store the FPU state of the first FPU on the exec stack frame, and hence the stack frame and the debugging tools would remain untouched. 1) 8 register FPU with integer only SIMD = slow fp performance
FPU and integer is contradition in terms. (-: 2) 8 register FPU and wait for an SIMD with single precision fp = slow fp performance now
Why do I need to "wait" for something? That is rather a question how I organize my vector unit. For all the decoding work, two register banks, each representing a vector of eight single precision registers would be rather ideal. But why stop there, I mean, you could also reorganize this as 4x4 unit or 2x8 unit. That's rather a question of organization and not a question of "slowness" or "fastness". The 68k FPU would be much more efficient with more scratch registers (the cost of saving and restoring extended precision FPU registers is very expensive).
I would not even work with extended precision in the vector unit. What for? The applications I would have in mind that would allow speedup by the FPU - multimedia decoding, namely - only require single precision. These are "killer applications" where one can really profit from new features and where one can easily implement a dispatcher in a corresponding datatype. Keeping the FPU extended precision makes more sense with 16 registers because of the register argument passing and reduced register saves and restores.
Look, 16 registers alone does not buy you much for the applications I have in mind. Despite, it creates potential incompatibilities because you need to save and restore the registers. Which do you think would cause the least incompatibility?
Have a dedicated unit that is only enabled for programs that use it. It is easy to add this as a flag on the exec stack frame that indicates whether the second FPU is busy or not, and programs that do not use it would use the same old stack frame.
Thus, a scalar FPU, 80 bits precision, as today. A vectorial unit, only enabled when required and whose context is only saved and restored when required, single precision only. Vectors of size eight or four, probably two sets of them.
-
Sorry, I don't get your argument. There are already two incompatible(!) MMU models, the 68030/68851 and the 68040/68060. Even within the same family, subtile differences exist, so a single program cannot depend on a single set of instructions already. Note again that the instructions and the programming logic is already different from MMU to MMU.
The argument is, don't create another incompatible MMU model and let us run all of the 68060 software that exists already. Anything worth running already works on a 68060.
Essentially I want to be able to run all 68060 software at the fastest speed possible (but no faster that it causes incompatibilities). Like I want my car to go as fast as possible but I'm not going to take out the seat belts, brakes, roll cage etc to save weight.
If after it's possible to run all 68060 software there is a future mode that can be enabled that is faster but only works with new age software then I don't have a problem with that (I probably won't use it but I won't care).
-
The argument is, don't create another incompatible MMU model and let us run all of the 68060 software that exists already. Anything worth running already works on a 68060.
Essentially I want to be able to run all 68060 software at the fastest speed possible (but no faster that it causes incompatibilities). Like I want my car to go as fast as possible but I'm not going to take out the seat belts, brakes, roll cage etc to save weight.
May I ask which software you currently use that goes down to the MMU directly?
-
May I ask which software you currently use that goes down to the MMU directly?
some versions of voodoo warp3d drivers? maybe shapeshifter for updating the display..
-
some versions of voodoo warp3d drivers? maybe shapeshifter for updating the display..
I can't tell you about the voodoo stuff. But for the Shapeshifter, we have at least MuEVD, so there is a well-defined compatibility layer for this kind of stuff.
-
May I ask which software you currently use that goes down to the MMU directly?
I don't have a 68060 currently, assume that when I do then I want to be able to run all software that runs on a 68060 and don't want to have to run new versions. I hoped that this would meet my needs, but it appears it won't.
I want the confidence that if I submit a bug report that it won't get closed as a won't fix because the software isn't popular enough & right now I don't have that confidence because the stated goal isn't to run all software.
-
Back in the days when I did lots of animation, VMM was a must. And it's no secret that I will want to run Linux on a fast new 68k, hehe.
-
Psxphil: also no fun to have bug reports in software closed as "won't fix" because author "only" has a real 68k system and you as user and customer has a 68k CPU that is ridden with all kinds of incompatibilities.
-
Something in the back of my head says that A3000 uses the MMU for Zorro3 bus initialization, but I could be all wrong about this.
-
Something in the back of my head says that A3000 uses the MMU for Zorro3 bus initialization, but I could be all wrong about this.
No, that's just a regular Kickstart, or - in case of the RAM-based kickstart - a patched version thereof that runs from a different start address.
-
No, that's just a regular Kickstart, or - in case of the RAM-based kickstart - a patched version thereof that runs from a different start address.
No, zorro 3 requires an mmu to work properly when Kickstart is in rom too. But you know that.
Exec uses the transparent translation registers, which are arguably part of the mmu even though they exist on parts that don't have an mmu (enabled at least). Then 68040.library/SetPatch/whatever takes over to make it fast (as long as you have an mmu).
http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html
Quite what will happen if the mmu isn't compatible but you use the standard 68040.library is anyones guess. What happened when 68060's turned up and people only had commodores 68040.library?
The a600 is the simplest Amiga, the only expansions possible are on the other side of gayle & IIRC there is no fast ram dma. Dealing with zorro 2/3 is going to be much more complex.
-
With CBM 68040.library and 68060 CPU it is crash party on bootup, from what I remember.
Oh well, this essencially says that current Phoenix... I mean apollo design plans do not fit well for A3000 and A4000 systems.
-
No, zorro 3 requires an mmu to work properly when Kickstart is in rom too.
Excuse me, but: No. Zorro III is just a bus technology. It does not require an MMU. The 68040 requires an MMU, but that is taken care of by the CPU library (and there is/would be one for the Phoenix). The 68030 should also enable its MMU due to a CPU bug (and there is a CPU library for the 68030). But that is all not related to Zorro III. Quite what will happen if the mmu isn't compatible but you use the standard 68040.library is anyones guess.
I cannot tell you what happens with other people's library, but if the MMU is not accessed like an 68040 CPU, then mine will detect the CPU as an 68EC040, i.e. an MMU-less processor. Or rather, it is not even the CPU library which does that, but rather the mmu.library which does. Thus, in case I add low-level support to *that* library, everything is fine. What happened when 68060's turned up and people only had commodores 68040.library?
SetPatch is quite able now to distinguish a 68040 from a 68060 and loads the right stuff. The a600 is the simplest Amiga, the only expansions possible are on the other side of gayle & IIRC there is no fast ram dma. Dealing with zorro 2/3 is going to be much more complex.
Not really. There is an established subsystem to deal with it, namely expansion.library. There is no need to worry about it. And no, Zorro itself does not require an MMU.
-
Excuse me, but: No. Zorro III is just a bus technology. It does not require an MMU.
I suspect you'll find that in practise it will, but time will tell eh.
Zorro 3 is flakey as hell, I don't envy anyone trying to make something compatible with everything (unless that too is not a priority), especially if you're going to deviate from all the established methods.
-
I suspect you'll find that in practise it will, but time will tell eh.
Zorro 3 is flakey as hell, I don't envy anyone trying to make something compatible with everything (unless that too is not a priority).
What exactly does the MMU do to the Zorro bus?
-
All the MMU could possibly do to the Zorro bus is 1 or more of the following:
1. Mark memory ranges as copyback cacheable.
2. Mark memory ranges as write-through cacheable.
3. Mark memory ranges as noncacheable.
4. Mark memory ranges as write-protected.
I don't know if kickstart requires an MMU to be present on Zorro III or not. It is certainly possible. Due to design or just by accident.
-
What exactly does the MMU do to the Zorro bus?
Essentially RAM is marked as cacheable, IO is marked as non cacheable.
Zorro has a cache inhibit line, but if you've already started a cache line burst then it's a bit late. You can probably design around it and live with any performance/compatibility issues.
Given some zorro 3 cards don't like 060 accelerators or even any gvp accelerators, I wouldn't say it was a particularly good idea to come up with too much deviation from existing access methods.
-
All the MMU could possibly do to the Zorro bus is 1 or more of the following:
1. Mark memory ranges as copyback cacheable.
2. Mark memory ranges as write-through cacheable.
3. Mark memory ranges as noncacheable.
4. Mark memory ranges as write-protected.
I don't know if kickstart requires an MMU to be present on Zorro III or not. It is certainly possible. Due to design or just by accident.
Well, Kickstart itself does not touch the MMU, only the transparent translation registers. It marks the entire Z-II space including the ROM as non-cachable, and the entire Z-III/32-bit expansion area as cacheable, "and hopes the best", i.e. that the board vendor took all precautions to make this a workable configuration. In general, you are right that this will likely go wrong if I/O ends up in the Zorro-III space, or if certain burst/caching configurations are not supported by the hardware, let it be by CPU bugs or board designs, but that's not really the fault of the Zorro bus. It is rather "by the lack of proper support of the CPU". Let it be as it is, yes, some I/O configurations that involve Zorro-III likely require the MMU to be enabled. So yes, I believe one can say "Zorro-III requires an MMU", somehow. A strange way of putting it, though. It's really the CPU that does.
-
Does the Phoenix core you have been working with, have all 4 TTR registers?
Are they compatible with 68060?
I think PsxPhill would be perfectly happy as long as the mini-MMU that is contained in ALL 68060 chips was included in the Phoenix/Apollo/68070/WhateverItIsCalled.
-
Does the Phoenix core you have been working with, have all 4 TTR registers?
Are they compatible with 68060?
No, the mini version does not have TTx registers at all. It has all the cachable areas hard-coded in the core AFAIK, so you cannot change anything at this time.
-
I think PsxPhill would be perfectly happy as long as the mini-MMU that is contained in ALL 68060 chips was included in the Phoenix/Apollo/68070/WhateverItIsCalled.
No, I want a full 68060 MMU as well. It can also support larger page sizes and I wouldn't be unhappy. I think a mips style mmu where you do table walking in code would be horrible, no other major cpu designer ever thought it was a good idea either.
-
No, I want a full 68060 MMU as well. It can also support larger page sizes and I wouldn't be unhappy.
Actually, now I'm confused about your wishes, because if you want to be *fully* compatible, then 4K and 8K pages would be sufficient because that is all the 68060 does support. In fact, the only page size that is currently used is 4K, and this is because (only) the lowest 4K remain unused by the Os. Thus, if you want to use something like MuFastZero, 4K is the only usable page size anyhow. I think a mips style mmu where you do table walking in code would be horrible, no other major cpu designer ever thought it was a good idea either.
That is not so much different for PPC, i.e. it has a fixed size ATC (address translation cache) and if a page descriptor does not fit in there, you need to remove another descriptor. I.e. it is necessary that the Os maintains the page descrptors. That's not specifically horrid, it means that the CPU design can be made much simpler. Given that you should actually never touch the MMU directly, I don't see why this is a problem.
-
Actually, now I'm confused about your wishes, because if you want to be *fully* compatible, then 4K and 8K pages would be sufficient because that is all the 68060 does support.
Why are you confused? I'm being pragmatic. 4k & 8k pages gives compatibility, larger pages gives you more functionality. I may never use the larger pages but if they can be added without harming compatibility then I'm not going to argue against them. Obviously if an extension turns out to cause compatibility issues then it should be reworked, that is the commitment that is missing.
Given that you should actually never touch the MMU directly, I don't see why this is a problem.
Why should I never touch the MMU directly? That sounds elitist. I definitely wouldn't help fund a project with that kind of ideal
-
So far, any touching of an MMU is higly hypothetical anyways, lol
-
Why are you confused? I'm being pragmatic. 4k & 8k pages gives compatibility, larger pages gives you more functionality.
Which type of functionality do you get with larger pages? They are only larger pages, after all. With typical memory sizes as found in the Amiga, 4K is actually quite good. For some debugging features actually even too large. Why should I never touch the MMU directly?
Why would you? If you do, you program is more or less "bound" to the hardware it runs on. This is quite a bad idea. The MMU is a "system level" tool, and the system provides you with interfaces to abstract from the hardware. Otherwise, you'll have to write your program (currently) at least four times, and run into a lot of compatibilty issues - given that the Os also requires the MMU for DMA or debugging. Hence, if there is an abstraction level to access a feature, use it.
-
But AmigaOS has no such abstraction, all tools and utilities that support MMU are third party AFAIK. And frankly I personally don't care much about MMU in context of AmigaOS, I just want it for Linux and *BSD. Only exception is paging to disk, which is very useful and almost a must when doing animation work within the limits of 128MB RAM.
-
IIRC it is not possible to boot any Amiga with a 68060 and any published Kickstart version only.
You need a bootrom at $F00000 or make your own modified Kickstart to not guru through the startup. MY Cyberstorm came with such a bootrom, and I expect all other solutions did too.
The 68060 simply came too late for C= to officially support it.
-
And this is different from 68040? There are people upgrading their 3640 cards with 68060 CPUs, wonder how that works out in that case, maybe with modified kickstart too.
Edit: so I heard with someone doing such upgrades, and except for the usual hoopla to load 68060.library, there are no changes done, the 3640 with adapter and 68060 boots up with unmodified kickstart. But maybe 68040 has same requirements, and bootrom is already present on 3640?
-
But maybe 68040 has same requirements, and bootrom is already present on 3640?
No, the 68040 is handled by Kickstart.
The missing bit is (I think - been a long time) to clear the "DFP—Disable Floating-Point Unit" bit in the PCR register and execute an FNOP before that.
IIRC it is the FPU tests that go wrong if this isn't done.
The 68040 does not have the PCR register.
If it simply works on a non-FPU 68060 I don't know.
-
IIRC it is not possible to boot any Amiga with a 68060 and any published Kickstart version only.
Well, yes and no. You cannot reliably boot the system with the 68060 because the FPU stack frame is different, not because the MMU is diffferent. The little bit of MMU exec uses for its initialization is actually identical between the 040 and 060. The system would (probably) run up to the point where someone tries to use the FPU (and would then crash), but that I do not remember. The boot ROM that disables the FPU until the 68060.library hooks in is currently the savest alternative.
-
But AmigaOS has no such abstraction
It does not? Nothing that is coming from CBM, but that is no surprise. all tools and utilities that support MMU are third party AFAIK.
Yes, but there are those parties that try to provide a generic interface to it and care about it, and those parties that provide specialized solutions for single applications and have lost track in updating their software... so make your pick. And frankly I personally don't care much about MMU in context of AmigaOS, I just want it for Linux and *BSD. Only exception is paging to disk, which is very useful and almost a must when doing animation work within the limits of 128MB RAM.
That is certainly true, but I wonder why that is a good application for Amiga Hardware, at least nowadays. Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.
-
Which type of functionality do you get with larger pages? They are only larger pages, after all. With typical memory sizes as found in the Amiga, 4K is actually quite good.
The only rational argument I heard for coming up with a different MMU was that the page size was too small. It was a concession, but I don't particularly care. If 4k is fine then it's another argument for keeping the MMU exactly the same.
Why would you? If you do, you program is more or less "bound" to the hardware it runs on. This is quite a bad idea. The MMU is a "system level" tool, and the system provides you with interfaces to abstract from the hardware. Otherwise, you'll have to write your program (currently) at least four times, and run into a lot of compatibilty issues - given that the Os also requires the MMU for DMA or debugging. Hence, if there is an abstraction level to access a feature, use it.
So there is only one operating system allowed and you get to do the MMU code for it? I don't like that kind of lock in, when a compatible MMU would allow you to run BSD or Linux. You might not want to do it, but your arguments seem more about you getting to provide the MMU support.
-
Which type of functionality do you get with larger pages? They are only larger pages, after all. With typical memory sizes as found in the Amiga, 4K is actually quite good.
The only rational argument I heard for coming up with a different MMU was that the page size was too small. It was a concession, but I don't particularly care. If 4k is fine then it's another argument for keeping the MMU exactly the same.
Why would you? If you do, you program is more or less "bound" to the hardware it runs on. This is quite a bad idea. The MMU is a "system level" tool, and the system provides you with interfaces to abstract from the hardware. Otherwise, you'll have to write your program (currently) at least four times, and run into a lot of compatibilty issues - given that the Os also requires the MMU for DMA or debugging. Hence, if there is an abstraction level to access a feature, use it.
So there is only one operating system allowed and you get to do the MMU code for it? I don't like that kind of lock in. "bug closed, won't fix, not running amigaos".
Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.
This is sounding more and more like a dictatorship. I get the impression that you want an incompatible MMU solution so everyone has to run MMULib.
-
May I ask which software you currently use that goes down to the MMU directly?
Enforcer, WHDload
http://www.sinz.org/Michael.Sinz/Enforcer/
http://whdload.de/docs/en/mmu.html
-
That is certainly true, but I wonder why that is a good application for Amiga Hardware, at least nowadays. Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.
Well, my favourite programs for animating just happens to be Amiga programs, they are your so called "killer apps", I know them, I enjoy using them and I have made money with them both in "entertainment" and scientific work. If you're saying "why that is a good application for Amiga hardware today", we may just as well drop it alltogether, right? As for Linux on m68k, it's a hobby I've had for 20 years now, maintaining Linux distros for old m68k systems, it never made any sense, but I enjoy it and would love to see newer and cheaper hardware, especially with more RAM. It would also broaden the use case for the Apollo core a lot if they make sure Linux and BSD is supported.
As for your MMU libs, by all means, it's a cool project, and I am probably not the only one who is mostly unaware of tools using them. Is there paging functionality available that use them?
-
If you're saying "why that is a good application for Amiga hardware today", we may just as well drop it alltogether, right?
Not exactly. I mean, most Linux applications are Open Source anyhow, and nowadays in much more modern versions available than in the Amiga days, so it's really simple and easy to migrate. The same does not go for native Amiga applications IMHO. Fore example, I'm still missing a "pixel-paint" program for Linux that is worth using (and no, gimp is not the right answer for this type of problem. It's just too complex for many simple tasks, and rather designed with another application in mind - photo editing namely). As for your MMU libs, by all means, it's a cool project, and I am probably not the only one who is mostly unaware of tools using them. Is there paging functionality available that use them?
As in "paging memory"? Yes, certainly. There is the "memory.library" which gives you all that, including to "mmap" files or create "virtual memory on demand". There is no "automatic virtual memory" basically because that simply cannot work, and I don't like programs that "cannot work", so I did not write one. But all the higher paging functionality is surely available. For example, all the "VMM" stuff for Amiga is simply "broken by design", no chance to get that working reliably.
-
This is sounding more and more like a dictatorship. I get the impression that you want an incompatible MMU solution so everyone has to run MMULib.
Actually, I want a solution that is easy to integrate into an FPGA core. The current MMU design of the 68K cores is pretty much "high level" and calls for microcode, but that's exactly what FPGAs are not designed for, so I understand Gunnar's hesitation to exactly re-implement that. All I'm trying is to find a way out and offer a bridge for that.
Another design would be to use a software-emulation of the MMU table walk, and this way the FPGA MMU could emulate a 68K MMU, with software support. That would pretty much work like the integer instruction emulation that is now in the simple Phoenix core for the first generation of Vampires. This design would also work, though it is necessarily requiring more complex software and is necessarily less performing.
For me, the easiest would be if I wouldn't have to touch any code, but that's unlikely to happen given the complexity of the task at hand and the performance and hardware implications. But calling it a "dicatorship to make you use my code" I find rather harsh. Just to remind you, all the other "system authors" no longer support anything of their stuff, so thanks for the flowers.
Your friendly dictator, Thomas
-
Enforcer, WHDload
http://www.sinz.org/Michael.Sinz/Enforcer/
http://whdload.de/docs/en/mmu.html
Enforcer is now called MuForce. Yes, it really is the same code. Mike offered the code, and I only removed the low-level stuff. All the high-level stuff is still Mike's code, so you don't loose anything, and gain compatibility - and future development and improvement. I would not run Enforcer nowadays anymore, or rather, would recommend its revised version.
WHDLoad I may accept as a possible application. Actually, personally consider this a rather bad hack, but I probably understand that some people want to continue to run badly written games. Note, however, that the MMU is probably your least problem with WHDLoad when running on the Phoenix. This core is *just too fast*, and I would not be surprised if a lot of games simply refuse to work because the timing is not at all the same anymore.
Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.
-
Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.
Wow! That's quite a statement.
I do believe most people buying FPGA hardware are looking to run old games. Switching off the FPGA is not a solution for people wanting standalone FPGA hardware to replace aging Amigas.
-
It would be really cool if we could pause the fpga via Amiga Amiga then an option to switch A500/A600 68000 mode, A1200/68020 mode etc
then the system just continues in this mode seamlessly would be nice for debugging asm.
- user friendly the Amiga way ..
-
The current MMU design of the 68K cores is pretty much "high level" and calls for microcode, but that's exactly what FPGAs are not designed for, so I understand Gunnar's hesitation to exactly re-implement that.
I'd like to see a technical explanation of why you can emulate a CPU but not an MMU with an FPGA. AFAIK his hesitance to adding an MMU was the latency. Using a MIPS (and apparently PPC) style MMU is not going to do much for latency when you run out of registers. But the exact same cache could be done using an MMU that is compatible and the slow path would still be faster than using the CPU.
-
Not exactly. I mean, most Linux applications are Open Source anyhow, and nowadays in much more modern versions available than in the Amiga days, so it's really simple and easy to migrate.
That makes no sense considering that latest kernels and toolchain compile and work fine on Amiga today - Linux on old Amiga hardware is way more modern than AmigaOS on same hardware can ever be.
I don't run Linux on 68k because I "must", I have all kinds of hardware and architectures running Linux, 68k is just one of many, and as long as it works fine, I don't see any point in stopping.
The same does not go for native Amiga applications IMHO. Fore example, I'm still missing a "pixel-paint" program for Linux that is worth using (and no, gimp is not the right answer for this type of problem. It's just too complex for many simple tasks, and rather designed with another application in mind - photo editing namely).
I agree, I keep using DPaint for all such work.
As in "paging memory"? Yes, certainly. There is the "memory.library" which gives you all that, including to "mmap" files or create "virtual memory on demand". There is no "automatic virtual memory" basically because that simply cannot work, and I don't like programs that "cannot work", so I did not write one. But all the higher paging functionality is surely available. For example, all the "VMM" stuff for Amiga is simply "broken by design", no chance to get that working reliably.
Well, question is really, can I set up a 1-2GB partition to use as raw swap to increase the ammount of system "Fast RAM", which Lightwave, DPaint etc can benefit from when I do longer high-res animations? It's really all I want and need, and why I use VMM.
-
Wow! That's quite a statement.
I do believe most people buying FPGA hardware are looking to run old games. Switching off the FPGA is not a solution for people wanting standalone FPGA hardware to replace aging Amigas.
Wow, why?? Have you been paying attention? If all you want is to run old games, then there is already _plenty_ of cheap and compaible hardware around, an FPGA accellerator is total utter overkill for that. On the other hand, if insisting on running ports of 15-20 year old PC games on your Amiga is your interest, them FPGA accelerator is perfect choice. Hopefully it will also make sense to use FPGA accelerator for legacy productivity software.
-
Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.
Fusion also used MMU directly IIRC (You could run MacOS 8.1 with swapmemory enabled).
ArtEffect IIRC offered some kind of swap memory but I don't know if it used MMU.
ADoom too IIRC (to perform c2p&refresh just the changed gfx)
Didn't StormC offer some option to use MMU for debugging?
VMem and other swap memory tools.
I think that using smaller pages (e.g. 256bytes is more effective for c2p and emulators/virtual machines) but I may be wrong.
-
Wow, why?? Have you been paying attention? If all you want is to run old games, then there is already _plenty_ of cheap and compaible hardware around, an FPGA accellerator is total utter overkill for that. On the other hand, if insisting on running ports of 15-20 year old PC games on your Amiga s your interest, them FPGA accelerator is perfect choice. Hopefully it will also make sense to use FPGA accelerator for legacy productivity software.
One of the biggest driving factors of FPGA hardware will be replacing aging Amiga systems. Accelerators are nice but won't help fix failing Amigas due to leaking batteries, failing capacitors, careless users, etc...
How popular would WinUAE be if it didn't handle old misbehaving software so well?
Why is WHDLoad so popular?
A standalone FPGA solution should have excellent compatibility options (even different cores would be OK), or it's popularity will be limited.
-
Stand alone FPGA solutions have existed for years already - there are myrads of boards and systems available, and for which variants of Minimig implementation runs fine already, with and without AGA support. The Apollo project is not about this.
-
One of the biggest driving factors of FPGA hardware will be replacing aging Amiga systems. Accelerators are nice but won't help fix failing Amigas due to leaking batteries, failing capacitors, careless users, etc...
How popular would WinUAE be if it didn't handle old misbehaving software so well?
Why is WHDLoad so popular?
A standalone FPGA solution should have excellent compatibility options (even different cores would be OK), or it's popularity will be limited.
Some enterprising soul could always port UAE over to Apollo/Vampire accelerated systems for those temperamental hardware banging games. Wouldn't that be ironic? Running an emulator for 68K classic Amigas on accelerated classic Amigas! Sort of like DosBox on PCs.
-
It should not be a problem to tell the Apollo core to "slow down" though, or just use a different core, like TG68, or MikeJ's core, that aim for compatibility and accuracy rather than superfastestest :)
-
I'd like to see a technical explanation of why you can emulate a CPU but not an MMU with an FPGA.
You *can* if you want to, but you probably do not *want to*. The current (small) Phoenix core does not implement the bitfield instructions, to give you an example. It could, but it does not because the complexity of these instructions is too high to make this feasible. A single bitfield instructions accesses between one and five bytes, dynymically, depending on register values. That's nothing the current pipeline can do. In the 68K, this is a microcoded instruction, i.e. it is slow.
Pretty much the same goes for the MMU table walk. It is a pretty complex algorithm, it requires to access an even larger number of bytes in a completely serial fashion, testing several conditions on the way. Yes, you can probably implement that on the FPGA and spend a lot of gates for that, but in reality, you probably simply do not want to. This part of MMU handling is also microcoded on real hardware, so you can now either add more complexity to add a microcode interpreter into the FPGA, or you can have it interpreted by the CPU core that is there anyhow, i.e. you can do it completely in software.
One way or another, it makes a lot of sense to split off the complex algorithms belonging either to instructions or CPU internals to eliminate complexity in the core. If you look at the current small core, a lot of the complex less used instructions are in software: ABCD and friends, MOVEP and friends, 64x64->64 arithmetic (the double-sized MULx and DIVx), and bitfields. And these are rather harmless compared to *some* of the MMU functions, namely the table walk.
I personally don't have to decide, but if I would have to, I would offload this stuff also to the CPU and build something simpler underneath.
-
Well, question is really, can I set up a 1-2GB partition to use as raw swap to increase the ammount of system "Fast RAM", which Lightwave, DPaint etc can benefit from when I do longer high-res animations? It's really all I want and need, and why I use VMM.
No, in the same way it does not work today. It may "appear to work" for you, but in reality, you only have been lucky. The problem with that is that "virtual memory" as delivered by VMM, or the memory library for that matter, does not satisfy an important contract physical memory does: Namely, you can access it no matter whether your task is in Forbid() state or not.
Thus, I do not even attempt to provide the impossible simply because virtual memory as implemented by VMM is "contradiction in terms". Given the current Amiga system, this cannot be made working reliably. It can be made working if applications know about the constraints when to access the memory and when not, and if there is a clear separatation between system memory and virtual memory. In reality, VMM is just guessing what programs probably ask for (virtual or real memory), and then probably get away with this in your case, but that's really it.
-
Wow! That's quite a statement.
I do believe most people buying FPGA hardware are looking to run old games. Switching off the FPGA is not a solution for people wanting standalone FPGA hardware to replace aging Amigas.
I don't think that then the FPGA solution or the Phoenix/Apollo core is then really what you are looking for. Yes, it can be turned off so the system runs then on a plain 68K CPU with native speed... In the same sense a fast 68060@50 is not really helpful for running old games. If I want to, I disable the turbo board and run the stuff on the 68000 in my A2000.
Same as for the 68060, the FPGA speed is probably too much for many badly written games in first place. The general guideline is that if the game is Os-friendly, it should usually run. But only few games are, and most authors did not really know well enough what they were doing.
WHDload is a combination of patching techniques, both into the game and into the Os, to fix the most obvious bugs the games had, but it seems very likely that *if* you want to make games run on the FPGA with WHDLoad (why? just use the 68K in the system anyhow...) then WHDLoad would have to support the whole FPGA core natively by a couple of support functions. As said, I would rather believe that the MMU is then probably the least problem.
-
Stand alone FPGA solutions have existed for years already - there are myrads of boards and systems available, and for which variants of Minimig implementation runs fine already, with and without AGA support. The Apollo project is not about this.
OK. Right, and compatibility with other FPGA solutions is excellent and/or improving. Compatibility with older software is high priority, with good reason.
This statement does not say Phoenix, it is about FPGA solutions in general:
Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.
I don't think that then the FPGA solution or the Phoenix/Apollo core is then really what you are looking for. Yes, it can be turned off so the system runs then on a plain 68K CPU with native speed... In the same sense a fast 68060@50 is not really helpful for running old games. If I want to, I disable the turbo board and run the stuff on the 68000 in my A2000.
Same as for the 68060, the FPGA speed is probably too much for many badly written games in first place. The general guideline is that if the game is Os-friendly, it should usually run. But only few games are, and most authors did not really know well enough what they were doing.
WHDload is a combination of patching techniques, both into the game and into the Os, to fix the most obvious bugs the games had, but it seems very likely that *if* you want to make games run on the FPGA with WHDLoad (why? just use the 68K in the system anyhow...) then WHDLoad would have to support the whole FPGA core natively by a couple of support functions. As said, I would rather believe that the MMU is then probably the least problem.
Right. Again, you can't "switch off" the FPGA in a standalone FPGA product. As I mentioned above, having the options for a performance (less compatible) core, and an option to choose an accurate (more compatible) core is fine - but for the product to be successful I believe a standalone FPGA product needs high compatibility one way or another.
Counter to your original statement, I think an FPGA solution is PERFECT for a scenario like this where you have the ability to switch cores depending on what you need at a given time.
-
Counter to your original statement, I think an FPGA solution is PERFECT for a scenario like this where you have the ability to switch cores depending on what you need at a given time.
Sorry, I don't quite understand what you are saying here. Currently, we are talking about an FPGA-based Turbo-Board for some Amigas. Thus, if you want compatibility, why would I want to load another core on the FPGA core? I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.
Plain simple 68K are available in the market, no problem. The problem is that the high-end processors (68060) are impossible to find, and *those* are out of production. Not the 68000. These are still available as new parts.
-
I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.
Only on an a500/a600/a1000/a2000. Anything else and you don't have a 68000, some of them will only have the fpga and to use the original cpu would require you to swap cards.
-
Sorry, I don't quite understand what you are saying here. Currently, we are talking about an FPGA-based Turbo-Board for some Amigas. Thus, if you want compatibility, why would I want to load another core on the FPGA core? I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.
Sorry, you are right. I lost track based on how the discussion was moving and forgot this thread is supposed to be about the A500/A600 expansion board only. My comments are more general, I am considering the standalone FPGA product which I would be more interested in.
-
Okay , this thread has gone to the abyss so I will stick my
neck out waiting for assembler axe to fall.
I suspect that this board WILL indeed be able to use WHDLoad
to play games without it's owners having to resort to cavemen
year of loading games from floppies.
1.Because WHDLoads runs 99.5 % of games on 060 at normal
speed because good old Amiga chipset is still used for that and
the fact that cpu just got 100 times faster doesn't matter
2.If it isn't so then it will be possible by using :
C:INeedWHDLoadNowTnx >NIL:
That new command will make mighty Phoenix return to ashes
of something like the speed of 10 Mips (it will allow us also
to use 128 MB memory as 1 MB isn't enough for WHDLoad)
and no disabling of card will be needed
Somebody tell me I'm right :hammer:
-
If I was to get one of the Vampire boards for my A500, I would want it to be compatible with all the software that runs on the A500!
I would also like to benefit from getting 50fps in 3D games like Gunship 2000, Frontier, Wing Commander, etc. In this scenario, disabling the FPGA isn't an option. However for other games, it is. I would also not like to reboot to switch between FPGA and native 68k, but that might be asking too much!
But people are definitely looking in the future to buy FPGA Amigas to replace broken Amigas, and to run their existing software, and benefit from faster performance (if only to play Alien Breed 3D II at full frame rates).
If implementing an existing 68k MMU model is too difficult in an FPGA due to whatever factors, and in 90% of cases using a new model that does work well isn't a problem (handled by the OS), then maybe the issue is getting the remaining MMU-using software patched. This is just a matter of time, and people have been waiting a long time already, so what's the problem here really?
Also, IMO, the admins should split this topic into two threads - "FPGA 68k Design Considerations" and "Testing Vampire on the A500/A600"
-
Only on an a500/a600/a1000/a2000. Anything else and you don't have a 68000, some of them will only have the fpga and to use the original cpu would require you to swap cards.
Kind of silly to expect an FPGA accelerator card to give your A1200, A3000 or A4000 compatibility with A500 - go buy a minimig already.
-
Kind of silly to expect an FPGA accelerator card to give your A1200, A3000 or A4000 compatibility with A500 - go buy a minimig already.
It's silly to think that an FPGA can't be used to run a 68000 core.
A minimig doesn't give you the real Amiga keyboard, real Amiga floppy drive etc.
Your suggestion is silly.
-
It's silly to think that an FPGA can't be used to run a 68000 core.
It can, but why? New 68Ks can be bought for cents, so if you really want a 68K only, why not just get one?
-
It's silly to think that an FPGA can't be used to run a 68000 core.
A minimig doesn't give you the real Amiga keyboard, real Amiga floppy drive etc.
Your suggestion is silly.
Well, good luck doing much usefull with a 68000 core on any of A1200, A3000 or A4000 - they were buildt for other CPUs than 68000, I would be surprized if they manage to boot into a useful state with a 68000.
-
It can, but why? New 68Ks can be bought for cents,
Amiga community does not always make cents :D
-
It can, but why? New 68Ks can be bought for cents, so if you really want a 68K only, why not just get one?
I didn't say I wanted a 68000 only. A 68000 on it's own doesn't really help, how do you suggest fitting it into an A4000 that also has an FPGA card in?
Well, good luck doing much usefull with a 68000 core on any of A1200, A3000 or A4000 - they were buildt for other CPUs than 68000, I would be surprized if they manage to boot into a useful state with a 68000.
It would boot fine. I ran kickstart 3.0 from an a1200 on an a500 back in the day. Plus it would be trivial to load a different kickstart anyway. If you think the motherboard would get upset because the FPGA is emulating a 68000 rather than an 030/040/060, then how do you think it will know??
-
I didn't say I wanted a 68000 only. A 68000 on it's own doesn't really help, how do you suggest fitting it into an A4000 that also has an FPGA card in?
I would not suggest fitting that at all. But as you say, you want an 68K compatible with absolute compatibility, but then it has to execute at 7Mhz with 68K instructions only. But that definition only fits to the original 68K. The A4000 is by that definition not compatible in first place because it does not have an 68K in it.
One way or another, I don't quite get your demands.
-
The T68 softcore is close to 68020 compatibility (and I'm still fixing it). It certainly boots up kick 3.0 on an AGA 1200 core no problem.
MikeJ
-
I would not suggest fitting that at all.
You quite plainly did, or did you think that buying a 68000 and placing it next to a A4000 would magically empower it with the ability to run unmodified 68000 code?
The only other option I can come up with is that you're just randomly saying crazy things hoping to "win" an argument, but I hope that is not the case.
The A4000 is by that definition not compatible in first place because it does not have an 68K in it.
One way or another, I don't quite get your demands.
I think you're trying too hard not to, but I'll play along.
If you have an fpga in your a4000 then it could easily have a 68000 core loaded into it that would run at 7mhz, it would be useful because of what you said. "The A4000 is by that definition not compatible in first place because it does not have an 68K in it. ", what I'm suggesting would make it more compatible for booting old disks than soft kicking and disabling caches.
-
You quite plainly did, or did you think that buying a 68000 and placing it next to a A4000 would magically empower it with the ability to run unmodified 68000 code?
The only other option I can come up with is that you're just randomly saying crazy things hoping to "win" an argument, but I hope that is not the case.
I think you're trying too hard not to, but I'll play along.
If you have an fpga in your a4000 then it could easily have a 68000 core loaded into it that would run at 7mhz, it would be useful because of what you said. "The A4000 is by that definition not compatible in first place because it does not have an 68K in it. ", what I'm suggesting would make it more compatible for booting old disks than soft kicking and disabling caches.
You're just trying to be argumentative as usual. If you want absolute and complete 100% compatibility then stick to using a classic Amiga and stop with all these ridiculous demands. If you don't like the Apollo/Phoenix, then don't use it! Or use it in your classic Amiga and remove it when you feel the need. The Apollo/Phoenix project will probably run 98% of the Amiga software out there without any problem. The other 2% will in most cases be demos or games that most people won't care about. Same story happened 25 years ago with the 68030 accelerators that I used to upgrade my classics. The software that had issues wasn't critical to my operations and I could always disable the accelerator....or use WHDLoad. It simply isn't reasonable or practical to expect hobbyist developers like Gunnar and Thomas nor professionals to spend 99% of their time shooting for 100% compatibility. Be happy that there's any new development period.
And there was never such a thing as 100% compatibility in the first place. I bought my first Amiga 2000 in an Army PX in Germany. It was an NTSC model and several PAL software packages and games simply wouldn't run on it even if I held down both mouse buttons and selected a PAL boot-up. I actually ended up buying a PAL Fat Agnus for it when I absolutely had to run those cranky bits of software. So you're asking for the ridiculous. Even the PC emulation software released by Commodore had problems across the same A500 lines. It ran fine on my system, but wouldn't recognize the keyboards on my boss' A500 due to Commodore using a slightly different keyboard controller in those units.
Or like I and a few others have suggested, use WHDLoad with the Apollo/Phoenix.
-
One way or another, I don't quite get your demands.
He is saying that we want 1 Amiga that "does everything".
It could load a 68000 core to be a 68000.
It could load a 68EC070 core to be a 68EC070.
It could load a 68070+MMU core to be a 68070+MMU.
etc. etc.
Apparently there is also a Mac-Compatible core and a Not Mac-Compatible core. Which seems like a reasonable compromise.
-
He is saying that we want 1 Amiga that "does everything".
It could load a 68000 core to be a 68000.
It could load a 68EC070 core to be a 68EC070.
It could load a 68070+MMU core to be a 68070+MMU.
etc. etc.
Apparently there is also a Mac-Compatible core and a Not Mac-Compatible core. Which seems like a reasonable compromise.
When is the last time in your memory that you had one device that "did everything"? Let me help you answer that......NEVER. I wish you guys would stop trying to impose unreasonable demands on a hobby such as Apollo/Phoenix.
As for your scenarios above, the FPGAs can do such things if someone develops the cores you're looking for. Get it thru your heads that Mac compatibility, MMUs, and 100% absolute compatibility are not the goals of this project and move on. Or better yet, learn to develop a core that YOU'RE happy with and stop whining.
-
When is the last time in your memory that you had one device that "did everything"? Let me help you answer that......NEVER. I wish you guys would stop trying to impose unreasonable demands on a hobby such as Apollo/Phoenix.
Chill out. I am not demanding anything. I was just explaining to Thor, the concept that psxphil was explaining, using different words.
As for your scenarios above, the FPGAs can do such things if someone develops the cores you're looking for. Get it thru your heads that Mac compatibility, MMUs, and 100% absolute compatibility are not the goals of this project and move on. Or better yet, learn to develop a core that YOU'RE happy with and stop whining.
/me casts RetaliatoryStrike +20 vs. Misdirected Rants
Gunnar already said there would be a Mac-Compatible version of the core.
Gunnar has also said, 512 bazillion times that 68070/Apollo would be 100% compatible.
If you don't like the way Gunnar is doing things then learn to develop a core that YOU'RE happy with and stop whining.
-
Gunnar already said there would be a Mac-Compatible version of the core.
Gunnar has also said, 512 bazillion times that 68070/Apollo would be 100% compatible.
If you don't like the way Gunnar is doing things then learn to develop a core that YOU'RE happy with and stop whining.
We're probably arguing in circles, but what endangers this project the most is IMHO still that there is not yet a quite clear-cut definition of its goals. Unlike other people, I don't think that the additional flexibility is actually adding to its success.
It's rather implying a certain risk, namely that people will create software that only runs in a specific configuration of the FPGA, causing a lot of dissatisfaction of the average user. If I would have to reboot the system and reprogram the FPGA just to load my next program, then that's not going to end up anywhere.
What I'm trying to find out here is which specific demands exist, and give my personal view on what I consider realistic or reasonable and what not. For example, a plain 68K emulation I consider unreasonable because that exists cheaply as hardware, so why bother the FPGA with that stuff. What I consider also not realistic at this point is adding potential sources of lack of forwards compatibility as in "new instructions" without actually knowing whether there is a demand for them.
Anyhow, we had this before, and I still afraid that I'm probably not yet too successful of getting the message accross. Nevermind.
-
Lets not split hairs. Everything I have worked on my A2000 with 030 and worked fine with an 060 in the same machine without whdload. As long as this is as compatible I would think this is just fine for compatibility sake.
Chris
-
Chill out. I am not demanding anything. I was just explaining to Thor, the concept that psxphil was explaining, using different words.
/me casts RetaliatoryStrike +20 vs. Misdirected Rants
Gunnar already said there would be a Mac-Compatible version of the core.
Gunnar has also said, 512 bazillion times that 68070/Apollo would be 100% compatible.
If you don't like the way Gunnar is doing things then learn to develop a core that YOU'RE happy with and stop whining.
Yeah, I know. Sorry if my comments seemed directed at you. They were directed at psxphill and my lack of attention to detail put you in the cross-hairs by mistake! LOL!
-
When is the last time in your memory that you had one device that "did everything"?
I'm not talking about doing everything, I'm talking about specific things which it should be capable of. It's field programmable, why wouldn't you be able to load a different cpu core into it? If you're saying that it's going to be locked down so only gunnars core can be used then there is no way I'd buy it.
Gunnar has also said, 512 bazillion times that 68070/Apollo would be 100% compatible.
The last postings I saw from gunnar here about the FPU & MMU doesn't suggest that is the case. But I guess it depends what you're claiming it's going to be 100% compatible with. It appears to be a mix of instructions and functionality from various 680x0 cpu cores, with his own additions and changes. It's likely the 100% will get downrated, especially if people start actively looking for ways to make software work on real hardware and not Apollo.
-
Could we stop going down the track of promising a 68k that will use modern software? It is distracting from current software releases.
No one should develop software that will only run on a faster than 060 processor. A few games might be the exception.
It is no longer fun when I am worrying about expansions and upgrades.
-
Could we stop going down the track of promising a 68k that will use modern software? It is distracting from current software releases.
No one should develop software that will only run on a faster than 060 processor. A few games might be the exception.
It is no longer fun when I am worrying about expansions and upgrades.
What software releases are u talking about. ?
-
It would boot fine. I ran kickstart 3.0 from an a1200 on an a500 back in the day. Plus it would be trivial to load a different kickstart anyway. If you think the motherboard would get upset because the FPGA is emulating a 68000 rather than an 030/040/060, then how do you think it will know??
So because kickstart 3.0 works on an A500, a 68000 will work in an A1200? Brilliant logic.
-
So because kickstart 3.0 works on an A500, a 68000 will work in an A1200? Brilliant logic.
It's the only problem you'd face, not insurmountable either as with an fpga you can jam in another rom and ignore the one on the motherboard.
Assuming it won't work because of some magic that the a1200 will reject a cpu core that is only running 68000 instructions is insane.
You're obviously trolling.
-
http://youtu.be/vLzhBGSyoCo
That video also gave the clear answer to my long lasting question - mac emulation is currently not working.
-
It's the only problem you'd face, not insurmountable either as with an fpga you can jam in another rom and ignore the one on the motherboard.
Assuming it won't work because of some magic that the a1200 will reject a cpu core that is only running 68000 instructions is insane.
You're obviously trolling.
Well, insane and trolling as I may be, but is it totally unthinkable that there is code in the kickstart and OS that may be confused by finding an AGA system with a 68000 CPU? What about A3000 and A4000 that also have Zorro III? I am curious if it would work.
-
Well, insane and trolling as I may be, but is it totally unthinkable that there is code in the kickstart and OS that may be confused by finding an AGA system with a 68000 CPU? What about A3000 and A4000 that also have Zorro III? I am curious if it would work.
Actually, the kickstart bootstrap code is all more or less identical, and everything in it runs on a plain 68K. The kickstarts do not differ in how they were compiled or assembled, just in the way which modules they include. Depending on the machine, the scsi.device may be present or not (or rather, one out of the several scsi.devices), workbench.library might be absent, and so on. But modules were all compiled and/or assembled from the same sources with the same options, so CPU compatibility is at kickstart level not really the problem.
-
Yes, I know that everything in kickstart is plain 68000, that much is obvious having assembled my own kickstarts for 68000 systems. Even in OS3.9 there is very little that requires 68020+ (and that workbench.library for no obvious reason does so in a boingbag annoys me, and ditto for a few commands in C: and a few other places). I am more curious about code that may or may not be confused because of the oddball combination of 68000 CPU and AGA chipset. But, in time there will be an FPGA acc card for 1200 and it will be more obvious what works and what doesn't.