Amiga.org
Amiga computer related discussion => Amiga Gaming => Topic started by: biggun on February 09, 2015, 06:31:48 AM
-
Hi
here is Video showing how ADOOM in full screen mode runs on Amiga 600.
http://youtu.be/bS_tgDB6g9U
-
Sounds better with the Prisma card
-
Awesome.
-
Sounds better with the Prisma card
;)
-
Hi
here is Video showing how ADOOM in full screen mode runs on Amiga 600.
http://youtu.be/bS_tgDB6g9U
Impressive...well done :)
Now can we have the same thing for 1200/3000/4000 please with a bigger FPGA and more memory... Thanks
-
Sounds better with the Prisma card
Regarding sound on A600.
The A600 is on its own fast enough to play MP3 in 44 Khz and 14bit quality.
Here is a video showing it:
http://www.kipper2k.com/a600mp3/newvid/newvid.html
I find that the MP3s in 14bit sound very good already...
-
Impressive...well done :)
Now can we have the same thing for 1200/3000/4000 please with a bigger FPGA and more memory... Thanks
The next generation cards are in testing and will come...
In parallel we work on making the CPU fully 68060 compatible.... But faster much faster...
Nova, when you ask for more memory..
Are the any games you work on, e.g. like Scumm games which need more than 64 MB ?
-
The next generation cards are in testing and will come...
In parallel we work on making the CPU fully 68060 compatible.... But faster much faster...
Nova, when you ask for more memory..
Are the any games you work on, e.g. like Scumm games which need more than 64 MB ?
Quake 2 really needs 128 MB, DosBox could probably also do with 128 MB.
NetSurf could certainly use as much memory as it can get.
It seems pointless to create new fast processor boards and then cripple them with limited FAST RAM. Ideally you'd go for 512 MB but if that's too expensive then go for 256 MB.
If we get enough MIPS then ambitious projects like DosBox can be usable on real hardware without using an RTG card.
-
If we get enough MIPS then ambitious projects like DosBox can be usable on real hardware without using an RTG card.
Yes with enough Mips you don't need Netsurf, then people
can use Internet Explorer in Windows running on PC-Task :-)
Regarding RTG, I think adding RTG to all the next card would be good.
With RTG and enough Mips Amiga will make a big jump in usability...
Are there any good games available to port which require 15/16/24 bit color?
-
Don't stop to put 512MB in. 128MB is plenty. I want to use it mostly for FPS and some limited internet.
Although, how about the addition of virtual memory on a solid state drive? That would be a modern solution to extra memory.
-
Quake 2 really needs 128 MB, DosBox could probably also do with 128 MB.
NetSurf could certainly use as much memory as it can get.
It seems pointless to create new fast processor boards and then cripple them with limited FAST RAM. Ideally you'd go for 512 MB but if that's too expensive then go for 256 MB.
If we get enough MIPS then ambitious projects like DosBox can be usable on real hardware without using an RTG card.
Total Chaos AGA needs 128MB minimum.
Total Chaos P96 / CGX needs 1024MB to 2048MB.
Ibrowse needs 2048MB
All web browsers need 2048MB
All gfx softwares need 2048MB
Professional Audio softwares need 2048MB
I agree it is a bit silly to make a superduper CPU and then just waste all its power with a tiny bit of fastram.
-
Although, how about the addition of virtual memory on a solid state drive? That would be a modern solution to extra memory.
It is easier to just put 2GB of ram on the card in the first place than to add an SSD with working virtual memory.
-
The next generation cards are in testing and will come...
In parallel we work on making the CPU fully 68060 compatible.... But faster much faster...
:banana::banana::banana::banana::banana:
-
Total Chaos AGA needs 128MB minimum.
Total Chaos P96 / CGX needs 1024MB to 2048MB.
Ibrowse needs 2048MB
All web browsers need 2048MB
All gfx softwares need 2048MB
Professional Audio softwares need 2048MB
I agree it is a bit silly to make a superduper CPU and then just waste all its power with a tiny bit of fastram.
IBrowse needs 2048 MB?
I cannot speak officially for Gunnar but the biggest option in near term will be 128 MB. The idea is to use off-the-shelf cards (much cheaper than anything custom) so it is limited to what is available and of course it is a question how much it costs. Vampire has 64 MB.
-
Google needs 2048MB to display my 30 tabs and so does Ibrowse.
You know that 24bit gfx files are really huge, right?
You know that animgifs are really huge, right?
-
Google needs 2048MB to display my 30 tabs and so does Ibrowse.
You know that 24bit gfx files are really huge, right?
You know that animgifs are really huge, right?
I have stopped using chrome. It has some major memory leaks issue. if you leave it running with some tabs ooen will gobble up 8gb of ram.
-
I have stopped using chrome. It has some major memory leaks issue. if you leave it running with some tabs ooen will gobble up 8gb of ram.
Run FlashBlock and watch your memoryleaks and CPU cycle leaks disappear.
Flash is evil.
-
Don't stop to put 512MB in. 128MB is plenty. I want to use it mostly for FPS and some limited internet.
Although, how about the addition of virtual memory on a solid state drive? That would be a modern solution to extra memory.
A modern solution to extra memory is extra memory since memory is not expensive these days.
-
A modern solution to extra memory is extra memory since memory is not expensive these days.
The discussion about 128 MB, or 512 MB or better 2000 MB of memory makes me smile a little.
Right now Igor CPU Card is positioned in the market as upgrade for old A600 systems.
Isn't Igor card the Vampire 600 priced similar as an ACA 500 ?
Or priced like another 68020 CPU card?
Please help me understand this.
My impression is some people want something real high end, right?
Did I get it right. That people would prefer to pay a premium to get a premium card?
On the other hand the Apollo/Phoenix Core can also
provide performance greater than 68060 for a price of a 68020 card.
So one could also make a budget card offering performance higher than 68060 for the price of a budget 68EC020 card.
So what do people want?
-
Well you will sell more cards with a fast core and limited fasram for sure but there always are people who want premium and will pay premium.
I would say start with affordable cards, feel the market and if there is enough interest AFTER the affordable cards are sold out then maybe make some premium cards, I for sure would buy a premium card for my A1200 but I will also buy the affordable card.
I will probably buy anything that you guys dish out for all Amigas I have :) I am quite happy with my Vampire 600 at it is :)
Keep up the good work guys!
-
The discussion about 128 MB, or 512 MB or better 2000 MB of memory makes me smile a little.
Right now Igor CPU Card is positioned in the market as upgrade for old A600 systems.
Isn't Igor card the Vampire 600 priced similar as an ACA 500 ?
Or priced like another 68020 CPU card?
Please help me understand this.
My impression is some people want something real high end, right?
Did I get it right. That people would prefer to pay a premium to get a premium card?
On the other hand the Apollo/Phoenix Core can also
provide performance greater than 68060 for a price of a 68020 card.
So one could also make a budget card offering performance higher than 68060 for the price of a budget 68EC020 card.
So what do people want?
I think a lot of people would a budget price card and 68060 level performance would be an added bonus.
Some are desperate for something as fast or faster than an 060 and considering 060 cards for A1200 are not far off the price of a Sam board might be willing to pay double for something slightly higher performance.
Personally I managed fine with 64MB on my B1260 back when I used an A1200 for everything.
What I wanted right now is something that'll turn my CD32 into a WHDload machine so 128MB would be overkill for me but 060 performance would be fun for playing some flight sims etc.
-
Does the vampire need a significant redesign to add all the extra goodness or can we simply put in a pin compatible (or as close as possible) memory and fpga upgrade at little extra cost?
I simply dont know what the cost is for each potential change. If we are taking about up to £10 to add an extra 64MB of ram then yes, as much as possible within reason. However, if it ramps up the cost significantly then that will be more than the majority will pay for and just leave the vampire600 as is and build something entirely new for those of us who want it. I'll be more than happy with the existing card in my A600, but could stretch to double/triple the price for a meaty CD32/A1200/big box variant.
What you and Igor, etc. have done with the Vampire600 is amazing.
-
Wouldn't it be cheaper to do a production run of low end cards first? High end cards should be pre-order.
-
Wouldn't it be cheaper to do a production run of low end cards first? High end cards should be pre-order.
What he said, that would be the best way to go about it :)
-
Run FlashBlock and watch your memoryleaks and CPU cycle leaks disappear.
Flash is evil.
Dont get the same issues with firefox :)
-
Total Chaos AGA needs 128MB minimum.
Total Chaos P96 / CGX needs 1024MB to 2048MB.
OK. I have not played it and now I know that I can't.
Ibrowse needs 2048MB
No.
All web browsers need 2048MB
No.
All gfx softwares need 2048MB
No. Are you familiar with the Amiga range of computers?
Professional Audio softwares need 2048MB
Be more specific. There is professional audio software that does not need 2048MB RAM.
I agree it is a bit silly to make a superduper CPU and then just waste all its power with a tiny bit of fastram.
It's silly to make a game for Amiga that uses 2048MB RAM.
-
@Linde
You are doing it wrong.
-
What the he** are you people smoking? What classic Amiga software requires 2GB of RAM? What classic Amiga system will ever have that much memory? Stick however much memory on this new card as you can to hit the price/performance "sweet spot" you're looking for. More is always better, of course. ;)
Also, I am firmly of the opinion that all of you have completely misconfigured computers and web browsers, if you're having these memory leaks and all these other problems. For the record, here is a screenshot of my Opera browser, displaying 99 open tabs and using only 2.4GB of memory, with zero performance issues. What can I say? I'm really ADD. ;)
-
You are doing it wrong.
What am I doing wrong? I think that you are doing something wrong if you meant for this post to be interesting or a valid response to anything that I said.
-
Could that be 2048 KB, i.e., 2 MB?
Because those numbers are silly.
-
I also do not see the point in limiting fast RAM, just go for 2GB and be done with it.
-
There is a huge difference between opening a bunch of tabs and doing work in a bunch of tabs. But yes seriously, why limit Fast RAM, why not max out directly on the board and be done with it?
-
I also do not see the point in limiting fast RAM, just go for 2GB and be done with it.
Oh hell man, why stop there? I can buy a 32GB stick of DDR3 at Newegg for $500. Why not just SMD those chips directly onto the new accelerator? Never mind that that would jack up the cost of the thing by at least that much. It's a cost/benefit analysis. ECON 100. ;)
-
I also do not see the point in limiting fast RAM, just go for 2GB and be done with it.
In an ideal world then yes that would be awesome but things are not always that simple. The OS has some issues accessing more than 512 MB and the hardware becomes more complicated to build (cost and time to develop go up). You also have to think about what applications would need that much, really there's not much.
As long as a new Accelerator had say 256 or 512 MB RAM then it should be enough.
The only other thing I'd consider adding is an HD controller (SATA would be ideal).
If you start adding graphics chips and USB etc the complexity goes up for the hardware and the development of the drivers to actually use these extras.
But the biggest issue I have with sticking an off-the-shelf FPGA computer inside a Classic case is that it will turn my A1200 into a retro keyboard!
If you simple want to 'play' around with an modern mini-computer then you can just buy a Raspberry Pi instead. You could even stick it in an old A1200 case if that's your thing ;)
I think the biggest market for an FPGA accelerator is in something cheap and configurable (can emulate different hardware 030/68000/060 all with or without FPU)...something very similar to the Vampire with more power and memory.
And then make it available for all Classic Amigas :)
-
I was going to suggest bootstrapping a Cray super computer to the board to crunch numbers (since there is no FPU), but even a full implementation of the 32-bit bus on an A4000 limits the accessible ram to 1 GB (you need addresses for the hardware) and on an X1000 is around 1.8 GB (barring extended memory mapping).
However since there exists a working design with quite adequate RAM for its market, why not start there? Then later, once the Cray addition is up and running, add more RAM.
-
You could even stick it in an old A1200 case if that's your thing ;)
Yes, but do make sure you power it off first.
-
Oh hell man, why stop there? I can buy a 32GB stick of DDR3 at Newegg for $500. Why not just SMD those chips directly onto the new accelerator? Never mind that that would jack up the cost of the thing by at least that much. It's a cost/benefit analysis. ECON 100. ;)
No. Wrong.
The reason you don't put 32GB of RAM on an Amiga is because Amiga is just like your Phone. It is a 32-bit computer and has a hard limit of 4GB of addressable memory space. So the most you could realistically use on an Amiga is 3GB.
Making new accellerator cards for Amigas in 2015 that have LESS RAM than an old 1990s Amiga is lame from the consumer's perspective. Amigas already had 256MB of ram waaaaay back in the previous century. Going backwards is not progress, it is congress.
And btw my W7 PC has had 32GB of ram for over a whole year now. Why can't my Amiga have 2 lousy GB?
-
" Going backwards is not progress, it is congress. "
Lol, classic! Gotta love it.
Chris
-
For the record, here is a screenshot of my Opera browser, displaying 99 open tabs and using only 2.4GB of memory, with zero performance issues. What can I say? I'm really ADD. ;)
That's a lot of RAM for 99 TABS, I got Firefox running with 55 TABS, all of them accessing Web pages, not empty, and I'm only using 524MB of RAM.
Staying on topic:
That's great performance out of the Vampire, finally someone showed Doom running on Vampire!
-
And btw my W7 PC has had 32GB of ram for over a whole year now. Why can't my Amiga have 2 lousy GB?
Hiya,
Like I said above, 2 GB in a new FPGA based accelerator would be very cool to see BUT if it's going to increase the cost or development time (significantly) then I don't think it's worth it considering how these boards will be used 99% of the time.
-
In an ideal world then yes that would be awesome but things are not always that simple. The OS has some issues accessing more than 512 MB and the hardware becomes more complicated to build (cost and time to develop go up).
You are getting your numbers mixed up my friend. :lol:
The issues you are thinking about happen at the 2048MB limit. There are no 512MB or 1024MB issues.
You should edit your message. :hammer:
-
That's a lot of RAM for 99 TABS, I got Firefox running with 55 TABS, all of them accessing Web pages, not empty, and I'm only using 524MB of RAM.
I have chrome going with 44 tabs, mostly all are different websites. REAL websites with lots of gfx. All flash is blocked with FlashBlock. But ads are not blocked so a lot of ram is being "wasted" with various animgifs and .jpgs + I am watching 1 episode of freely distributable Star Trek in a video player + I have some torrents going.
Total RAM usage 12.4GB
If I fire up WinUAE then it goes up to around 14.4GB
If my Bill Gates compatible personal computer is allowed to use 14.4GB then I think it is only fair to let Amiga compatible computers use a small tiny little 2GB.
-
Since the future upgrades will be using an off the shelf development board with 128MB on it, that's the only realistic option for this generation of devices. The limited IO of the development board is almost certainly all being used to interface with the rest of the Amiga system and the peripherals on the daughterboard so adding more (really) fast RAM is a non-starter. If you were designing it from scratch you'd probably have at least 512MB but designing and building a board like that needs expertise, time and money. 128MB should be plenty for most tasks. How many people have more than that now on their classic Amiga? Has any 68k accelerator ever had more than 128MB as standard? It's twice as much as the Vampire 600.
-
No. Wrong.
The reason you don't put 32GB of RAM on an Amiga is because Amiga is just like your Phone. It is a 32-bit computer and has a hard limit of 4GB of addressable memory space. So the most you could realistically use on an Amiga is 3GB.
No. Wrong.
Bank switching has been around for decades. Or set it up as a ram disk. Or a RAD:. There's ways it could be used.
Also, we were pointing out with humorous over-exaggeration the absurdity of your previous claims that all web browsers/graphics programs/music programs "require" 2GB of memory. Which is just absolutely ridiculous and not true.
You've got a bad attitude, buddy. I get that you're some "great programmer" of a game no one can play because they don't have 2GB of memory in their classic systems. I also understand that you've had a lot of health issues making you grumpy, but I've got metal plates and screws holding my spine together, so I'm pretty grumpy, too, but I still suck it up and play full-contact sports every day. So if you crawled out from under your rock just to tell people they're "No. Wrong." all the time, you can go back to it.
Whatever, I'm done here.
-
Off Topic (of what a great demo of the Vampire running Doom):
The A600 is NOT a 32-bit computer.
-
No. Wrong.
Bank switching has been around for decades. Or set it up as a ram disk. Or a RAD:. There's ways it could be used.
Also, we were pointing out with humorous over-exaggeration the absurdity of your previous claims that all web browsers/graphics programs/music programs "require" 2GB of memory. Which is just absolutely ridiculous and not true.
You've got a bad attitude, buddy. I get that you're some "great programmer" of a game no one can play because they don't have 2GB of memory in their classic systems. I also understand that you've had a lot of health issues making you grumpy, but I've got metal plates and screws holding my spine together, so I'm pretty grumpy, too, but I still suck it up and play full-contact sports every day. So if you crawled out from under your rock just to tell people they're "No. Wrong." all the time, you can go back to it.
Whatever, I'm done here.
Dude I wasn't grumpy at you. Sorry I didn't plaster smileys everywhere. Here this is just4u :)
I was just explaining that there are actual logical reasons why people only ask for a couple of gigs of ram for Amigas.
P.S. Bank switching sux. That isn't grumpy. That's a fact, jack. :biglaugh:
p.p.s. If I was grumpy I would insult you or at the very least throw in a bunch of exclamation points. I know how to work the exclamation point key. Here look I will prove it to you!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! OR I COULD TYPE AT YOU IN ALL CAPS or I could say STFU! Ok this concludes how to detect grumpiness 101 :roflmao::roflmao:
-
I just want my Amiga Pi with minimum 256Mb of RAM, at least AGA, and of course more MI
PS than my old 80Mhz 060 could put out. HDMI out would be a bonus as would USB.
One thing I do know though, and mind you, this feeling might change when I get even older, but for now, I can careless about trying to keep up original hardware, and am just in the mood for a faster than hell, classic generation FPGA clone.
-
Go with a virtual memory solution... Solid state drives are one dollar a gigabyte.
-
The A600 is NOT a 32-bit computer.
A600 is a 32-bit computer.
A600 can ONLY run 32-bit software.
A600 has 16 general purpose 32-bit registers.
A600 only understands 32-bit RAM.
A600 can move 32-bits of data from point A to point B in a single instruction because it is a 32-bit computer.
A600 has a 4GB ram barrier just like all 32-bit computers, because it is a 32-bit computer.
A600 runs many thousands of 32-bit softwares because it is a 32-bit computer.
A600 cannot run 64-bit software because it is a 32-bit computer.
A600 cannot run 24-bit software because it is a 32-bit computer.
A600 cannot run 16-bit software because it is a 32-bit computer.
A600 cannot run 8-bit software because it is a 32-bit computer.
A600 cannot run 4-bit software because it is a 32-bit computer.
The reason A600 software works on A1200 and A4000 and on the 68060 and 68040 without a recompile is they are all 32-bit computers to start with so the software just automatically works.
The A600 is permanently perpetually stuck in 32-bit mode forever and ever and ever. There is no way to switch into 64 bit mode. It can't be downgraded into 24-bit mode. It can't be downgraded into 16-bit mode. It is just STUCK at 32-bit mode period. The End.
-
Go with a virtual memory solution... Solid state drives are one dollar a gigabyte.
SSDs use NAND Flash chips which are not randomly accessible. They have gigantic page sizes. They are not a replacement for RAM.
SSD's make great hard drives though. (as long as you stay away from that 3-bit Samsung NAND Flash, in which they drop down to merely good).
-
Go with a virtual memory solution... Solid state drives are one dollar a gigabyte.
Less than that if you use USD's
-
A600 is a 32-bit computer.
A600 can ONLY run 32-bit software.
A600 has 16 general purpose 32-bit registers.
A600 only understands 32-bit RAM.
A600 can move 32-bits of data from point A to point B in a single instruction because it is a 32-bit computer.
A600 has a 4GB ram barrier just like all 32-bit computers, because it is a 32-bit computer.
A600 runs many thousands of 32-bit softwares because it is a 32-bit computer.
A600 cannot run 64-bit software because it is a 32-bit computer.
A600 cannot run 24-bit software because it is a 32-bit computer.
A600 cannot run 16-bit software because it is a 32-bit computer.
A600 cannot run 8-bit software because it is a 32-bit computer.
A600 cannot run 4-bit software because it is a 32-bit computer.
[snip rest of rant]
The Motorola 68000 ("'sixty-eight-thousand'"; also called the m68k or Motorola 68k, "sixty-eight-k") is a 16/32-bit[1] CISC microprocessor core designed and marketed by Motorola Semiconductor Products Sector (now Freescale Semiconductor). Introduced in 1979 with HMOS technology as the first member of the successful 32-bit m68k family of microprocessors, it is generally software forward compatible with the rest of the line despite being limited to a 16-bit wide external bus.[2] After 35 years in production, the 68000 architecture is still in use.
- From Wikipedia.
Or if you prefer: "M68000 8-/16-/32-Bit Microprocessors User's Manual" from Freescale's own website. ;)
http://cache.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf
This is almost kind of fun. I don't even have to try to prove your statements incorrect. ;)
-
[snip rest of rant]
- From Wikipedia.
Or if you prefer: "M68000 8-/16-/32-Bit Microprocessors User's Manual" from Freescale's own website. ;)
http://cache.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf
This is almost kind of fun. I don't even have to try to prove your statements incorrect. ;)
Just try to ignore him. He refuses to be educated.
-
ChaosLord is right, the rest of you are ignorant clueless dumbasses, and you insist on proving that fact over and over and over again on these forums. It hurts reading all this ignorance, you guys have been here long enough to wise up already!!!
-
ChaosLord is right, the rest of you are ignorant clueless dumbasses, and you insist on proving that fact over and over and over again on these forums. It hurts reading all this ignorance, you guys have been here long enough to wise up already!!!
I say the same thing every time I see any of your posts. :furious:
...and thread being locked by a mod in 3... 2... :roflmao:
:griping: :griping: :griping:
-
Well, what does it take to educate you sheeple? You link to the PDF at Freescale and gloat about it, but clearly is not capable of comprehending the content and its implications. And you go on personal attacks against the one who _is_ correct here.
-
Odd, the Wikipedia site (http://en.wikipedia.org/wiki/Amiga_500) states, "It utilizes a Motorola 68000 microprocessor running at 7.15909 MHz (http://en.wikipedia.org/wiki/MHz) (NTSC) or 7.09379 MHz (PAL). The CPU is 32-bit internally, but uses a 16-bit data bus and 24-bit address bus, providing a maximum of 16 MB of address space (http://en.wikipedia.org/wiki/Address_space)."
Granted there are differences between an A600 and an A500, but 16 MB to 2 GB must have folks screaming (as in this thread) to the Wiki site to fix their information to make the A600 address 32-bits on a 24-bit address bus.
-
You know, my A600 has a whopping 32MB of Fast RAM - how does that work you think?
-
Here's a clue - it is not the A600 that does any addressing!
-
Odd, the Wikipedia site (http://en.wikipedia.org/wiki/Amiga_500) states, "It utilizes a Motorola 68000 microprocessor running at 7.15909 MHz (http://en.wikipedia.org/wiki/MHz) (NTSC) or 7.09379 MHz (PAL). The CPU is 32-bit internally, but uses a 16-bit data bus and 24-bit address bus, providing a maximum of 16 MB of address space (http://en.wikipedia.org/wiki/Address_space)."
Granted there are differences between an A600 and an A500, but 16 MB to 2 GB must have folks screaming (as in this thread) to the Wiki site to fix their information to make the A600 address 32-bits on a 24-bit address bus.
http://www.cpu-world.com/CPUs/68000/
CPU-World says the same thing. But clearly it doesn't matter how many links to the correct information you post, if people insist on being ignorant. :roflmao:
-
Wait, wait, I've got one more good one. I've saved this flyer for over 20 years, for just this moment of Internet fame! But clearly even Commodore was wrong when they called it 16/32-bit, right? :roflmao: :roflmao:
-
What is wrong with you guys? This thread is about Vampire600, 68000 soft core in an FPGA - the 68000 on the A600 mother board is disabled, just like it is with my Apollo630 card, the softcore 68000 can easily be fully 32bit, it is not restricted by old legacy limitations.
-
No Commodore was not wrong, noone here is wrong except you guys who wave around arguments that mind boggingly speak against you, to "win" a discussion on a topic you clearly understand very little of. It is mind dumbing to witness.
-
Going back to topic:
Wilst I do see the benefits of this enhanced cores at faster speed, I wanted to know how do they compare with a motorola cpu at the same frequency. I mean, are these new cores more efficient, are they better microcoded? Or are they only beneficial at higher speeds than their motorola counterparts?
-
No Commodore was not wrong, noone here is wrong except you guys who wave around arguments that mind boggingly speak against you, to "win" a discussion on a topic you clearly understand very little of. It is mind dumbing to witness.
Ibrowse needs 2048MB
All web browsers need 2048MB
All gfx softwares need 2048MB
Professional Audio softwares need 2048MB
A600 is a 32-bit computer.
A600 can ONLY run 32-bit software.
A600 only understands 32-bit RAM.
A600 has a 4GB ram barrier just like all 32-bit computers, because it is a 32-bit computer.
This thread so full of absurdity and exaggeration that it's almost laughable. Next you guys will be saying "My A600 can go to the moon... when I strap on my optional Aerojet Rocketdyne RS-25 engine upgrade." :laugh1:
Where's my popcorn? :laugh1:
Oh well, carry on, OP. Demo looks very nice! :)
-
Well, lack of RAM is one of the major reasons why we lack a modern featured web browser for AmigaOS3 - modern browsers need more RAM, web pages today are resource hungry, number of open tabs alone is meaningless, try doing some work in them too! Working with gfx requires RAM too - I have done my share of animation on Amiga and know very well how limiting 128MB or even 256MB of RAM can be, and ditto if you do audio work, paging to disk is very annoying and also requires MMU features in the softcore to work - much easier to just have more *real* RAM.
-
This AGA port needs 400 MIPS to be usable (give or take)
[youtube]1Am-3TjsOWo[/youtube]
Maybe one day ;)
-
It couldn't possibly have anything to do with lack of developers? But hey, more ram is always good, especially if you're buying! :pint:
-
The lack of features in the OS and limitations in the hardware scare many developers away.
-
Boo!
-
This thread just reminded me that I need to optimize something. Oh yeah, that's right… my time! :lol:
-
I just decided it would be better to lock this thread than continue. Not funny.
-
This AGA port needs 400 MIPS to be usable (give or take)
Maybe one day ;)
How to you estimate the 400 Mips requirement?
How many times faster than a 50 Mhz 68060 would the system need to be?
-
Making new accellerator cards for Amigas in 2015 that have LESS RAM than an old 1990s Amiga is lame from the consumer's perspective. Amigas already had 256MB of ram waaaaay back in the previous century.
This is a very simple to understand question of price.
Designing a small CPU accelerator with 1 or 2 memory chips on board
and a limited number of PCD layers in one taks that takes a certain time to do and to test.
Desiging a CPU accelerator which has many times more memroy chips, more PCD layer and or even DIMM sockets where you will need to test various DIMMS is a project which takes much longer.
The first project might need 3 month of pure working time.
A dedicated hoppy developer like Igor Majsta can do this using his Winter and Summer holidays and the weekends in between them. This means such a project could be done in parallel to having a normal job.
The second project will take longer, many month longer.
This means it will not only take longer but also take more money to do.
Now the AMIGA market is not really big.
Does it make sense for an developer to take 6 month unpaid holiday from work
to be able finish to accellerator in time?
Can this lost income be compensated by selling Amiga CPU card with more memory?
My guess is that the most sensible solution is to focus on developing a good working, well tested CPU card for a good price.
-
The A600 is permanently perpetually stuck in 32-bit mode forever and ever and ever. There is no way to switch into 64 bit mode. It can't be downgraded into 24-bit mode. It can't be downgraded into 16-bit mode. It is just STUCK at 32-bit mode period. The End.
Hmm actually this is all not true what you say.
The A600 was shipped with a 16/32 bit CPU runnign in 24bit address mode.
So be default you run 32bit code, and of couse you can also run 16bit and 8bit instructions.,
And default the CPU support 24bit address mode.
The Vampire CPU upgrade which this topic is about now replaces the CPU completely.
The Phoenix is SuperScalar and fully 32bit and of course also offers 32bit address mode.
Now enabling 64bit addresses in Phoenix takes me a *smile*.
This is would absolutely be possible to turn all your existing old AMIGAs into 64bit systems.
-
This is would absolutely be possible to turn all your existing old AMIGAs into 64bit systems.
Oh snap! :banana:
Can you go into any more detail about what this would entail? I assume at minimum every application would need to be re-coded? Or would it be that existing applications would still run, and you'd just have the option to write 64-bit programs as well? Sort of like how Windows 64-bit can run either 64-bit or 32-bit software?
-
No. Wrong.
The reason you don't put 32GB of RAM on an Amiga is because Amiga is just like your Phone. It is a 32-bit computer and has a hard limit of 4GB of addressable memory space. So the most you could realistically use on an Amiga is 3GB.
Making new accellerator cards for Amigas in 2015 that have LESS RAM than an old 1990s Amiga is lame from the consumer's perspective. Amigas already had 256MB of ram waaaaay back in the previous century. Going backwards is not progress, it is congress.
And btw my W7 PC has had 32GB of ram for over a whole year now. Why can't my Amiga have 2 lousy GB?
my phone is 64bit
-
Hey, you can glue an AMD64 chip onto the 68000 and call it a 64bit upgrade!! Just as usefull!! Anything AmigaOS is stuck in 32bit forever, and for some even that is too much.
-
Oh snap! :banana:
Can you go into any more detail about what this would entail? I assume at minimum every application would need to be re-coded? Or would it be that existing applications would still run, and you'd just have the option to write 64-bit programs as well? Sort of like how Windows 64-bit can run either 64-bit or 32-bit software?
It is planned that it is compatible so existing software works. To use new features software has to be recompiled and we need adapted compilers. That is already in planning.
-
The lack of features in the OS and limitations in the hardware scare many developers away.
There is Aros 68k that can be adapted to anything because all sources are available
-
I take it there isnt a compatible single chip upgrade to the current 64 MB?
-
Well, lack of RAM is one of the major reasons why we lack a modern featured web browser for AmigaOS3 - modern browsers need more RAM, web pages today are resource hungry, number of open tabs alone is meaningless, try doing some work in them too! Working with gfx requires RAM too - I have done my share of animation on Amiga and know very well how limiting 128MB or even 256MB of RAM can be, and ditto if you do audio work, paging to disk is very annoying and also requires MMU features in the softcore to work - much easier to just have more *real* RAM.
We have discussed that on the apollo forum too. Of course more RAM are nice to have and we had the same discussions there too. The project is a compromise between wishes and what is realistic. We need a affordable and realistic path that neither needs 10 years to do nor millions of dollars to invest so using off-the-shelve components that are tested and sold already are the only chance to get something in near future to a low price. And that limits the options of course. I personal would be for "premium" options later for people who are willing to spend more money but for now it is better to have a "mass-solution" (if we can say that in the small market) than a expensive premium option that is only sold in low numbers. Developers need urgently a better platform with more RAM and more processing power and other new features. I do not know how many of the veterans (or any) will support the new 68k platform again because market has changed a lot in the last twenty years but I know that any developer only seriously look at a platform when there is new hardware available. So I (as many others) wait urgently for new hardware now and we do need it now and not after more years of development.
Another opinion of me that not everyone (expecially in the "NG" community) shares is "Back to the future". "NG" as the idea to move developers and users to a new modern hardware platform has failed, not only most users are active on 68k but also most compilers/dev environments,libraries and software is still 68k so for me the best chance for a future are the combination of real hardware based on FPGA on one side and emulation with UAE running (almost) everywhere on the other.
-
I take it there isnt a compatible single chip upgrade to the current 64 MB?
What do you mean?
-
I'm pretty sure 64-bit (memory) addressing is different from running 64-bit instructions.
I suppose it would be another speed boost for any software ported to a 64-bit 68k.
-
Here is a link to the next add-on for the Vampire: http://www.ebay.com/itm/Cray-1-Supercomputer-Memory-Board-Re-Engraving-Certificate-of-Authentically/111586542735?_trksid=p2047675.c100009.m1982&_trkparms=aid%3D777000%26algo%3DABA.MBE%26ao%3D1%26asc%3D28795%26meid%3Dc556e9e6caa841aba49adc5e0e8a8752%26pid%3D100009%26rk%3D1%26rkt%3D1%26sd%3D251832508033
It won't add that much to the cost...
-
What do you mean?
Like when the rasp pi was upgraded from 256 to 512MB of ram with little extra cost involved. I believe it was a straight part swap.
-
Like when the rasp pi was upgraded from 256 to 512MB of ram with little extra cost involved. I believe it was a straight part swap.
I do not know if it si possible on the Vampire but the other new cards will be ready off-the-shelve cards so I do not believe that you can add RAM.
-
Give me the core used in the video pretty please with sugar on top, my Vampire 600 board want's it ;)
-
I do not know if it si possible on the Vampire but the other new cards will be ready off-the-shelve cards so I do not believe that you can add RAM.
People should learn to have realistic expections - then the risk for dissapointment is lower.
People also need to make realistic comparisons:
For example:
The ACA500 offer 2 MB memory and about 1.0 CPU MIPS
Igors V600 offers 64 MB fast memory and about 80 CPU MIPS
Realistic expectations is to double the values again.
-
I've never used that benchmarking program you have on the bringup page but why does it give 6985.3 mhz as the cpu speed? I know it will be fast but I don't think that kind of speed is possible.
-
Like when the rasp pi was upgraded from 256 to 512MB of ram with little extra cost involved. I believe it was a straight part swap.
up to a 1GB on current pi sitting infront of me :)
-
People should learn to have realistic expections - then the risk for dissapointment is lower.
I think the vast majority are in agreement. I'm more than happy with the idea of 80mips + 64MB in my A600. Anything else you can give us is a bonus.
Is this still the plan? If so, how much for option 3?
1) Vampire 600
64MB
Status: Sold by Kipper
2) Vampire 500
64 MB
IDE
Status: in Beta-test (mainly used by Igor)
3) Apollo/Phoenix
128 MB
SDCard
(lots of extra features ...)
Status: in Beta-Testing (10 boards atm)
-
Well, lack of RAM is one of the major reasons why we lack a modern featured web browser for AmigaOS3 - modern browsers need more RAM, web pages today are resource hungry, number of open tabs alone is meaningless, try doing some work in them too! Working with gfx requires RAM too - I have done my share of animation on Amiga and know very well how limiting 128MB or even 256MB of RAM can be, and ditto if you do audio work, paging to disk is very annoying and also requires MMU features in the softcore to work - much easier to just have more *real* RAM.
There is always some specialist use case that can benefit from more RAM. I do data processing work that requires RAM in the tens and twenties of gigabytes. I browse the web with many tabs open. The question is, then, is the additional RAM worth more than the additional cost in development time, component price and board design? Is there software that will significantly benefit from it (Total Chaos and other specialist cases aside)? Would the relatively slow CPU, although fast in the 68k Amiga world, be sufficient for a modern featured web browser? Is being able to work actively in 50 tabs important enough to enough people to warrant the additional complexity?
The web browser problem is such a horribly ill-defined one as well. Tab usage seems to scale with RAM availability, and you can always make the argument that you *need* more RAM to support the weird habits you have acquired by being spoiled by a more modern, relevant and powerful architecture. Web page complexity tendencies also scale with ubiquitous RAM and CPU availability, and a lot of websites seem to operate on the assumption that I can dedicate a lot of my CPU time to rendering their Javascript animations. Animated GIFs? Outdated technology that, instead of benefitting from hi-color graphics and modern encoding technology, encodes 8-bit frames with run length compression, which with the dithering required to make most of them look somewhat acceptable, turns into huge files.
The basis of this sad development is the assumption of increasingly ubiquitous computing power, which happens at a much faster rate than the development of the 68k Amiga, and the Amiga will never catch up. The fact remains that you don't need 2 GB of RAM to surf the web.
-
Here is a link to the next add-on for the Vampire: http://www.ebay.com/itm/Cray-1-Supercomputer-Memory-Board-Re-Engraving-Certificate-of-Authentically/111586542735?_trksid=p2047675.c100009.m1982&_trkparms=aid%3D777000%26algo%3DABA.MBE%26ao%3D1%26asc%3D28795%26meid%3Dc556e9e6caa841aba49adc5e0e8a8752%26pid%3D100009%26rk%3D1%26rkt%3D1%26sd%3D251832508033
It won't add that much to the cost...
I was looking last night they have a whole Cray on there, starting at $12,000 (plus the need for a truck to haul it for you). I'm sure @kolla and @ChaosLord would be glad to front the costs of that. :roflmao:
-
People should learn to have realistic expections - then the risk for dissapointment is lower.
People also need to make realistic comparisons:
For example:
The ACA500 offer 2 MB memory and about 1.0 CPU MIPS
Igors V600 offers 64 MB fast memory and about 80 CPU MIPS
Realistic expectations is to double the values again.
:)
My sentiment is the same as NovaCoder; 128/256/512 megabyte would be great, but as Olaf mentioned; its about development cost/time and production overhead. I think the majority of the posters here would be more than happy to have their A1200 upgraded to 060 and 64 megs.
But as soon as people start with a "wishlist" they tend to run a bit amok ;)
I wouldnt take it as a critizism of your product, but people like to dream regardless of realism.
If/when this card becomes available for my A1200 I will line up for sure.
My Blizzard 030 with 16 megabytes is okish, but 060 with 64 (or more) megs would be damn sweet.
Thanks for the ADoom demostration btw!
-
There is always some specialist use case that can benefit from more RAM. I do data processing work that requires RAM in the tens and twenties of gigabytes. I browse the web with many tabs open. The question is, then, is the additional RAM worth more than the additional cost in development time, component price and board design? Is there software that will significantly benefit from it (Total Chaos and other specialist cases aside)? Would the relatively slow CPU, although fast in the 68k Amiga world, be sufficient for a modern featured web browser? Is being able to work actively in 50 tabs important enough to enough people to warrant the additional complexity?
The web browser problem is such a horribly ill-defined one as well. Tab usage seems to scale with RAM availability, and you can always make the argument that you *need* more RAM to support the weird habits you have acquired by being spoiled by a more modern, relevant and powerful architecture. Web page complexity tendencies also scale with ubiquitous RAM and CPU availability, and a lot of websites seem to operate on the assumption that I can dedicate a lot of my CPU time to rendering their Javascript animations. Animated GIFs? Outdated technology that, instead of benefitting from hi-color graphics and modern encoding technology, encodes 8-bit frames with run length compression, which with the dithering required to make most of them look somewhat acceptable, turns into huge files.
The basis of this sad development is the assumption of increasingly ubiquitous computing power, which happens at a much faster rate than the development of the 68k Amiga, and the Amiga will never catch up. The fact remains that you don't need 2 GB of RAM to surf the web.
it depends on what you want to do with it. If you want to use it for professional work and to browse the web including Youtube and so on 128 MB are of course not enough. If you want to run the newest ego-shooter 128 MB would not be enough either. If you want to beat standard PCs 128 MB are not enough either.
If you have a primary working system and want to have additionally a simple, affordable system that is fun to use then it is enough. It is much more than we have now. Everybody can buy a 4 GB system next door if he want, for Amiga there are no other options. If the people requesting that develop such a system fine, if they invest plenty of money in development everything is doable and fine too. If they both lack skills and money they have to take and use what is available. Nobody is forced to.
-
:)
My sentiment is the same as NovaCoder; 128/256/512 megabyte would be great, but as Olaf mentioned; its about development cost/time and production overhead. I think the majority of the posters here would be more than happy to have their A1200 upgraded to 060 and 64 megs.
But as soon as people start with a "wishlist" they tend to run a bit amok ;)
I wouldnt take it as a critizism of your product, but people like to dream regardless of realism.
If/when this card becomes available for my A1200 I will line up for sure.
My Blizzard 030 with 16 megabytes is okish, but 060 with 64 (or more) megs would be damn sweet.
Thanks for the ADoom demostration btw!
dreaming is the base of all innovations in the world but you must somehow return to earth finally.
-
:)
My sentiment is the same as NovaCoder; 128/256/512 megabyte would be great, but as Olaf mentioned; its about development cost/time and production overhead. I think the majority of the posters here would be more than happy to have their A1200 upgraded to 060 and 64 megs.
But as soon as people start with a "wishlist" they tend to run a bit amok ;)
I wouldnt take it as a critizism of your product, but people like to dream regardless of realism.
If/when this card becomes available for my A1200 I will line up for sure.
My Blizzard 030 with 16 megabytes is okish, but 060 with 64 (or more) megs would be damn sweet.
Thanks for the ADoom demostration btw!
For example we discussed about a standalone system. It would be great but it adds a lot of development time to it (for example for the drivers). We should be realistic. Behind Apollo project are a small group of dedicated hardware developers that can do a lot of things but no wonders. Custom hardware would be unaffordable for many (I know the calculation for the Natami parts), people would have moaned then why spending more money on that than for a much better standard PC. There are compromises necessary.
-
OlafS3; all understandable and valid points :)
Im no coder or hardware guy, so out of curiosity, what are the implications of;
"Regarding RTG, I think adding RTG to all the next card would be good.
With RTG and enough Mips Amiga will make a big jump in usability..."
Quoted Biggun on thread post #9.
I have Indivision in my A1200, and would the RTG part of the future Vipercard affect this?
That aside, any other info regarding your thoughts of performance of RTG?
I realise its just something you are thinking about, so nothing is decided/set in stone.
-
OlafS3; all understandable and valid points :)
Im no coder or hardware guy, so out of curiosity, what are the implications of;
"Regarding RTG, I think adding RTG to all the next card would be good.
With RTG and enough Mips Amiga will make a big jump in usability..."
Quoted Biggun on thread post #9.
I have Indivision in my A1200, and would the RTG part of the future Vipercard affect this?
That aside, any other info regarding your thoughts of performance of RTG?
I realise its just something you are thinking about, so nothing is decided/set in stone.
I am no "hardware guy" too so I try to explain it in my words.
For A500 there is a card in testing that uses a standard FPGA card that is normally used in industry. This includes modern monitor output, LAN, 128 MB and a bigger FPGA than on Vampire. The Vampire FPGA is only big enough for a special version of Apollo (not all features like FPU integrated/enabled) so the Vampire will stay what it is, a accellerator with 64 MB RAM running on A600 with ECS. The A500 card has a bigger FPGA so you can add fancy features like a new amiga chipset with better features and RTG so when all is included/implemented the A500 will be only keyboard and ports, the rest will run on the card.
Gunnar has promised cards for all models but you have to start somewhere :). So there will certainly be something for A1200 too.
-
i think it seems to be going very good course. vampire is a hardware that is out of the door and proven working. it is a good demonstration of what may be yet possible, it is comparatively low cost and it is available. we can speculate about future models, with more ram more logic space, more features like fpu, additional interfaces like usb or rtg. but the general direction is right, to concentrate on general purpose improvements rather than highly specialized add ons.
-
Hi All,
just thought i'd chip in with my 2 cents worth.
For hardware addons there has to be a sliding scale, from budget to high end. As already mentioned, we can ask/expect the most possible out of future upgrades but with high end upgrades comes time and money for the development costs.
Should we wait much much longer to get all the bells and whistles like massive ram that i think the majority of people would not get the benefit from or should we try to appeal to the masses. I think the present goals are good. Get the boards out with planned features and then if there is time/interest then do more development. So often a lot of hardware becomes vapourware due to it changing direction and real life issues that affect development. There are very few people developing for the community, Igor has done an outstanding job with the hardware and the Apollo team the same for the software, too much deviation from a planned course leads to chaos, confusion and frustration.
Full steam ahead with the planned features
I did another video showing a little more of the core running at 60MIPS. Compatibility with games is very good, still some hiccups but all accel boards have them
https://www.youtube.com/watch?v=N6KYtdpnMdA&feature=youtu.be (https://www.youtube.com/watch?v=N6KYtdpnMdA&feature=youtu.be)
-
I'm interested to see what kind of performance DOSBox and possibly PC-Task (or even PC-x) gets on the new core.
-
The problem with pc-task is that the timing is all sorts of wrong.
Even on my amithlon box (which reports to be running 68040@4800 mips (seems pretty close to actual speed)) the timing goes crazy, even when assigning 256Meg to the translation cache/buffer.
It's nice and fast, but it's inconsistent. Two seconds at about 100 fps for ms-dos quake, then 1 second at about 3 fps. Probably hasn't been noticed by many people as there's very few machines running 68k code as fast as my amithlon box (c2d@4.05ghz).
Win9x does work, but you're limited to vesa.
All in all it's probably the best possible option for 68k systems when it comes to pc emulation, but don't expect it to be a great option, regardless of speed for some tasks.
Considerably faster than Dosbox, but not as consistant, nor does it emulate particular hardware as Dosbox does (gfx is a simple vesa frame buffer in pc-task). Neither is ideal, but between the two you can get a pretty good experience if you have enough grunt.
As for ADoom on the a600, that's not too bad at all. Roughly half of what I used to get on my 1st Pentium system, which isn't bad for an a600.
-
it depends on what you want to do with it. If you want to use it for professional work and to browse the web including Youtube and so on 128 MB are of course not enough. If you want to run the newest ego-shooter 128 MB would not be enough either. If you want to beat standard PCs 128 MB are not enough either.
If you want to play the newest ego-shooter or watch youtube, 68K Amiga just isn't a viable alternative. I don't really mind people wanting this, but ChaosLord makes things up ("you need 2 GB to use IBrowse") and uses that as a basis to call the project "silly", and kolla outright calls the people that disagree with ChaosLord "dumbasses". That strikes me as damn rude, and there is an egotistical quality to ChaosLord's requests for more RAM. The project *needs* more RAM for what? To support his game (how does it even spend all that RAM?)? To support his obscure needs in general? That strikes me as silly, if anything.
-
The problem with pc-task is that the timing is all sorts of wrong.
Even on my amithlon box (which reports to be running 68040@4800 mips (seems pretty close to actual speed)) the timing goes crazy, even when assigning 256Meg to the translation cache/buffer.
It's nice and fast, but it's inconsistent. Two seconds at about 100 fps for ms-dos quake, then 1 second at about 3 fps. Probably hasn't been noticed by many people as there's very few machines running 68k code as fast as my amithlon box (c2d@4.05ghz).
Win9x does work, but you're limited to vesa.
All in all it's probably the best possible option for 68k systems when it comes to pc emulation, but don't expect it to be a great option, regardless of speed for some tasks.
Considerably faster than Dosbox, but not as consistant, nor does it emulate particular hardware as Dosbox does (gfx is a simple vesa frame buffer in pc-task). Neither is ideal, but between the two you can get a pretty good experience if you have enough grunt.
Interesting. I wonder if one can get away with an NT-based OS on it (3.51 or 4.x would be probably the best - I doubt very seriously if Win2000 would install on PC-Task!)
-
Well, I think it is pretty dumb to be loud and gloating about issues one have limited knowledge about, and when it is repeated and repeated, with a rudiculing and patrionizing tone too, yeah - dumbass is a pretty mild term I think.
-
Well, I think it is pretty dumb to be loud and gloating about issues one have limited knowledge about, and when it is repeated and repeated, with a rudiculing and patrionizing tone too, yeah - dumbass is a pretty mild term I think.
Dude, quit trolling. You and ChaosLord have clearly been proven wrong. You have not backed up one single claim with any sort of valid statistic. Take your public shaming like a man, and kindly STFU and get off this thread, so it can return to the more civilized discussion it was becoming last night. :whack:
-
For me, 64MB in an A1200 is a much unwanted downgrade, my aging A1200 already has 192MB and for the work the Amiga is actually usable for - simple 2D animation - 192MB is limiting. In my A4000 I can fill up the zorro bus with 1GB of RAM, but then I have no space for other cards. Only viable option for legacy software is really emulation.
In my view, to put 2GB on the card is well worth it. I would make a card that is essencially an FPGA computer, with a lot of RAM, some flash and I/O, and use that as base for all Amiga computers with different connection board for the various models.
64bit memory addressing for m68k has no use unless you have more RAM anyways.
-
Dude, quit trolling. You and ChaosLord have clearly been proven wrong. You have not backed up one single claim with any sort of valid statistic. Take your public shaming like a man, and kindly STFU and get off this thread, so it can return to the more civilized discussion it was becoming last night. :whack:
I am not trolling. Everything you have posted clearly says all the way that m68k is a 32bit architecture to run 32bit instructions, and for anything AmigaOS compatible - 32bit addressing - I cannot believe we must have this old stupid argument after all these years!!!
But - whatever - if it makes you happy to think 68000 is not 32bit enough for you, then keep believing, just stop the evangelizing of misinformation!
I have a Minimig, a so called A500 clone, with a 68SEC000 CPU - is it 32bit enough?
-
Is an A500 with a 68010 no longer an A500?
-
For me, 64MB in an A1200 is a much unwanted downgrade.
Why do you talk about this?
Did anyone ever say that A1200 Vampire cards would have 64 MB memory ?
No ...
The A600 card has 64 MB.
And 64 MB and 80 Mips is the best one could ever get for an A600.
-
Kind of makes you think twice about posting demos, doesn't it?
-
Niding said "I think the majority of the posters here would be more than happy to have their A1200 upgraded to 060 and 64 megs." which may very well be true, but I'm not one of them. 128MB would also be a downgrade, so what is the plan for Vampire1200?
As for 64bit addressing m68k and hacking AROS to support it - what ever for?! m68k supported adressing 2GB of RAM way back in early 90ies, if not before, and yet we are not even able to make use of _that_ today.
-
I am not trolling. Everything you have posted clearly says all the way that m68k is a 32bit architecture to run 32bit instructions, and for anything AmigaOS compatible - 32bit addressing - I cannot believe we must have this old stupid argument after all these years!!!
But - whatever - if it makes you happy to think 68000 is not 32bit enough for you, then keep believing, just stop the evangelizing of misinformation!
I have a Minimig, a so called A500 clone, with a 68SEC000 CPU - is it 32bit enough?
Dude, you're a joke. Motorola's own product literature states that the 68000 has a 16-bit data bus and a 24-bit address bus, and a maximum of 16MB of address space. I've backed this up with links to Wikipedia and CPU-World. Even Commodore's own product literature from the era calls the 68000-driven A500 a "16-bit computer" or a "16/32-bit computer". All of this was to refute ChaosLord's absurd claims that (among other things) "a standard A600 is fully 32-bit and can support 4GB of memory". Which it can't. Sorry, it just can't. Not in standard, unmodified form. Sure, if you hack in some other kind of processor, you can increase its limits. And many people have done this. Not rocket science. But a stock A600 is not a fully 32-bit computer and cannot support 4GB of RAM. Sorry you got all butt-hurt about that.
This is really, pretty simple. As you say, "I cannot believe we must have this old stupid argument after all these years!!!" and polluting this other guy's interesting thread with "Internet arguments". Bye.
-
Niding said "I think the majority of the posters here would be more than happy to have their A1200 upgraded to 060 and 64 megs." which may very well be true, but I'm not one of them.
Then go away so @biggun can talk about his new card.
-
Then CD32 is also not a 32bit console, and no m68k Amiga ever, for that matter.
-
Wow! Just watched the video on YouTube of Doom running on Amiga 600 and it was surely very impressive! :) Thanks to the developers for creating such a powerful piece of hardware for us! If I lived near you, I'd buy you a -----> :drink:
-
Why do you talk about this?
The A600 card has 64 MB.
And 64 MB and 80 Mips is the best one could ever get for an A600.
Seeing this video now leaves me with a slightly bad wish for a version that fits over my Minimig's 68000 CPU, just like an A600.
Yes I know its not likely to be technically feasible or very worth while as they are not that many minimig's out there and a newer FPGA clone Amiga is the a better solution, but for some odd reason adding a faster FPGA CPU to my FPGA clone A600 just sounds fun :-)
Anyway keep up the good work I really enjoyed the video and when your A600 board becomes available I may just need to add an A600 to my Computer collection.
-
For me, 64MB in an A1200 is a much unwanted downgrade, my aging A1200 already has 192MB and for the work the Amiga is actually usable for - simple 2D animation - 192MB is limiting. In my A4000 I can fill up the zorro bus with 1GB of RAM, but then I have no space for other cards. Only viable option for legacy software is really emulation.
In my view, to put 2GB on the card is well worth it. I would make a card that is essencially an FPGA computer, with a lot of RAM, some flash and I/O, and use that as base for all Amiga computers with different connection board for the various models.
64bit memory addressing for m68k has no use unless you have more RAM anyways.
for most Amiga users 64 MB and expecially 128 MB are a upgrade and we need to lift the average user hardware level and not the level of a few power users. Software (if commercial or as freeware or shareware) is alsways developed for the average user. Nobody is against more RAM, I would have no problem with 4 GB either but it is simply no option if you do not custom hardware. Custom hardware is too expensive. So if you see it as a "downgrade" you do not need to buy it. And there are good reasons for this strategy. If you have a reasonable how to deliver affordable hardware with 2GB RAM and FPGA just say it. We will certainly discuss it. As long as there is not a better plan we will stick to what we have.
-
Hey, you can glue an AMD64 chip onto the 68000 and call it a 64bit upgrade!! Just as usefull!! Anything AmigaOS is stuck in 32bit forever, and for some even that is too much.
you should start thinking before posting
-
All this back and forth...
Seems simple to me. Pack as much speed and memory as physically possible within a given price. RAM is pretty cheap these days. If, for instance, you can add 2GiB of memory and an 060 class CPU for even twice the price of a 128MiB based solution then do it. In reality I doubt it will really increase the cost by such a large factor.
2GiB may seem vast for a 68K machine but it simply means applications can work on larger projects and more applications can be open at once (as long as they are not CPU bound).
One technical point, if you are implementing an MMU, you might get some big tables.
If there are other, hardware based reasons for sticking to smaller memory sizes, then that's fair enough.
-
Moderators should not enter the fray with an opinion that can't be argued because they are a "Moderator." This seems to be quite common with the result of a user being banned.
-
All this back and forth...
Seems simple to me. Pack as much speed and memory as physically possible within a given price. RAM is pretty cheap these days. If, for instance, you can add 2GiB of memory and an 060 class CPU for even twice the price of a 128MiB based solution then do it. In reality I doubt it will really increase the cost by such a large factor.
2GiB may seem vast for a 68K machine but it simply means applications can work on larger projects and more applications can be open at once (as long as they are not CPU bound).
One technical point, if you are implementing an MMU, you might get some big tables.
If there are other, hardware based reasons for sticking to smaller memory sizes, then that's fair enough.
The price for RAM chips are not the problem. The Vampire is how it is with its 64 MB RAM. The new boards are based on off-the-shelve boards that have the advantage to be cheap. These boards have a certain amount of RAM. You can of course make a custom board that would be much more expensive or you take a premium board that is more expensive too. I am sure there will be more advanced options with more RAM in future. For me it is more important to have a general technical lift of the whole user base than just a small number of power users.
-
Moderators should not enter the fray with an opinion that can't be argued because they are a "Moderator." This seems to be quite common with the result of a user being banned.
Huh? The previous post is my opinion on the subject at hand. Not a moderation statement. If you think my opinion on adding as much ram as reasonably possible is invalid, nobody is going to get banned... Lol
-
Moderators should not enter the fray with an opinion that can't be argued because they are a "Moderator." This seems to be quite common with the result of a user being banned.
he has just said his opinion
-
Users are not allowed to argue with Moderators
-
Users are not allowed to argue with Moderators
Arguing with moderators is one of my favorite hobbies :-)
-
The price for RAM chips are not the problem. The Vampire is how it is with its 64 MB RAM. The new boards are based on off-the-shelve boards that have the advantage to be cheap. These boards have a certain amount of RAM. You can of course make a custom board that would be much more expensive or you take a premium board that is more expensive too. I am sure there will be more advanced options with more RAM in future. For me it is more important to have a general technical lift of the whole user base than just a small number of power users.
So it's the off-the-shelf board underpinning the project that limits the amount of memory? If so, then that's a reasonable trade-off.
I don't think the term "power user" really fits an Amiga enthusiast.
Anyway, if a 68060 class expansion with GiB levels of RAM ever shows up for A1200 and so on, I'd definitely be interested. Alas my A600 is long dead :(
-
So it's the off-the-shelf board underpinning the project that limits the amount of memory? If so, then that's a reasonable trade-off.
I don't think the term "power user" really fits an Amiga enthusiast.
Anyway, if a 68060 class expansion with GiB levels of RAM ever shows up for A1200 and so on, I'd definitely be interested. Alas my A600 is long dead :(
the bigger card will be for A500
if a Amiga user needs 2 GB RAM I would call him a "power user" :-)
-
Users are not allowed to argue with Moderators
Shush, then :lol:
-
Rule violations:
"Amiga.org Webmasters' or Moderators' discretion:
Criticism of moderation decisions or the deletion of posts"
-
the bigger card will be for A500
if a Amiga user needs 2 GB RAM I would call him a "power user" :-)
I didn't need a 1.25 GB HDD for my A1200 in 1994 but I still went for it. You always find a use for more resource.
Incidentally, that drive still works 21 years later :)
-
I didn't need a 1.25 GB HDD for my A1200 in 1994 but I still went for it. You always find a use for more resource.
Incidentally, that drive still works 21 years later :)
Fantastic! What's the make & model of that puppy? :D
-
Rule violations:
"Amiga.org Webmasters' or Moderators' discretion:
Criticism of moderation decisions or the deletion of posts"
Seriously? You're pulling my leg, right?!
Just to be clear, in case you really are serious. Users aren't supposed to argue moderator's moderation decisions publicly. Do you see a moderation decision here?
Moderators are still users and are allowed opinions on whatever is being discussed. At least when I last checked.
-
I didn't need a 1.25 GB HDD for my A1200 in 1994 but I still went for it. You always find a use for more resource.
Incidentally, that drive still works 21 years later :)
I have a problem when I have to use the original low resolutions. If you normally use RTG you do not want to go back :-)
Of course you can never have enough resources. I see it now as a start of a new path and just the beginning. In future there will be better options.
-
Fantastic! What's the make & model of that puppy? :D
Seagate Medalist, slimline 3.5 inch, "fast ATA", or vanilla IDE as it is otherwise known ;)
-
I have a problem when I have to use the original low resolutions. If you normally use RTG you do not want to go back :-)
True. The Bvision was the single biggest upgrade to my system since the first accelerator I installed (from vanilla 14MHz EC020/2MiB chip to full 25MHz 040 with 16MiB 60ns fast). Productivity software really does get transformed moving from AGA hires laced to flicker free RGB modes. I used a 1600x1200 75Hz 16-bit Workbench for years, though 1280x1024 is better on my ageing eyes these days.
-
Seagate Medalist, slimline 3.5 inch, "fast ATA", or vanilla IDE as it is otherwise known ;)
Nice! I still got a few Quantum Fireball drives from 1-4GB that works like a charm :D Always ahd luck with Quantum drives :D
Also had a big old 5.25" Quantum Bigfoot at 1.28GB but traded that some 10 years ago :( But it probably still works haha :)
-
Seagate Medalist, slimline 3.5 inch, "fast ATA", or vanilla IDE as it is otherwise known ;)
Nice! Yeah, Seagate and Quantum, always seemed to have pretty good luck with those two brands. I'm still stinging from a 500GB WD drive that I had to send in to a "clean room" recovery, after it crashed on my sister after only a year, taking with it all her European vacation pictures. $600 for that recovery job, I got her an external backup drive the following Christmas!! :laugh1:
Now I'm jealous of your Bvision resolutions, too. Can't get that on my Spectrum! ;)
-
The price for RAM chips are not the problem. The Vampire is how it is with its 64 MB RAM. The new boards are based on off-the-shelve boards that have the advantage to be cheap. These boards have a certain amount of RAM....
This is what they're using, Am I correct?
http://parts.arrow.com/item/detail/arrow-development-tools/bemicrocv#ggQF
-
If you want more RAM use a big box Amiga. Otherwise there is an emulator that costs nothing.
-
Seriously? You're pulling my leg, right?!
he is just trying to reverse apply what he understood of the discussion when the real problems with the (so called) new appointed moderators have been the case, only the opposite direction. almost everybody sure understands you are posting your opinions here, and not being moderating or whatever. lets go on with substantial discussion, then.
-
I am not trolling.
well, you are not, but you could have refrained to call other names even if it was in return. your opinion might be disputable (see thors post) but even if you are right, which you technically might be, it would be better if you and tcl would refrain from turning this thread in an ot. ´we are witnessing a positive development that has been questioned enough.
tcl, welcome back, btw.
-
Where is Thor's post? And I'm sorry for being straight forward instead of doing passive-aggressive sarcastic replies like certain others here. If soneone posts dumb erronous stuff over and over, it should be perfectly fine to point it out. Oldsmobile does not even _try_ to see what TCL was stating, he and others went straight to ridicule and patrionizing. Why should we be ok with that?
-
@kolla
sorry i dont seem to find the post i was sure to be referring before, still tcl orthodox style of posting may make it over the top, and your discussion on 16/32 bit issue doesnt actually h3lp it. i understand that you might take your issue with less technically skilled, but there is a ladder to climb for everybody.
as one cheering this development for long and seeing it adjusted for the best benefit of the community, i check in, even though i dont have machine to run it now, id say, we need to line up and help, as long as we don make us dependant on it.
-
How to you estimate the 400 Mips requirement?
How many times faster than a 50 Mhz 68060 would the system need to be?
400 MIPS was just a guess, I know that 100 MIPS on my 060 falls a long way short.
WinUAE with 800 MIPS and it flies :)
-
@kolla
sorry i dont seem to find the post i was sure to be referring before, still tcl orthodox style of posting may make it over the top, and your discussion on 16/32 bit issue doesnt actually h3lp it. i understand that you might take your issue with less technically skilled, but there is a ladder to climb for everybody.
@wawrzon - I appreciate your calm and balanced approach to this discussion. When I see such obvious absurdity related to a subject I'm fairly passionate about, I tend to respond with flip sarcasm and over-exaggeration. However I take offense to the line "with less technically skilled". I'm sure everyone on this forum has their own levels of technical proficiency. I can't judge yours, you can't judge mine, etc.
Now on the discussion, so far on this thread we have seen tcl and kolla make statements that "The A600/68000 architecture is fully 32-bit, is only 32-bit, and will only ever be 32-bit". That it "can address a full 4GB of RAM". That Ibrowse and most other common Amiga productivity apps "require 2GB of memory". They've called OP "silly" for only including 64MB of memory in his A600 accelerator, completely ignoring that their designs are based on a well-defined cost/benefit analysis. They've called others "fools" and "dumbasses" for disagreeing with their statements, despite not offering a shred of documentary evidence to the contrary.
I'm not too old to learn. If I'm wrong, prove me wrong. Post a link to a whitepaper, or to the manual of Ibrowse showing where it says it "requires 2GB of memory". Surely that shouldn't be too hard to dig up, right? So far I have posted links and photos of technical documentation from Motorola/Freescale, Wikipedia, CPU-World, and even Commodore, backing up that the A500/A600-era 68000 architecture was considered 16/32-bit, even at that time. They've also seen OP post that he can easily enable 64-bit execution in their new FPGA cores (which is awesome and something I'd love to hear more about!). So far all they've posted has been opinion and conjecture.
This is a dumb argument and I have no dog in this fight, so I'll just close with a quote from one of my favorite movies, Interstellar:
"Alright Murph, you wanna talk science?
Don't just tell me that you're afraid of some ghost. No, you gotta go further.
You have to record the facts, analyze...
...get to the how and the why and present your conclusions. Deal?"
"Deal. -All right!"
#posted from my A2000 with 24MB of memory, and Ibrowse. :D
-
Back OT, I would prefer to have a one that has fast 060 with a fast buss, plenty of memory,"loved 128M on my Tek card before it died" and SATA. I'll take 1 for my A2000 & A4000T.
PS: the 4KT really should have 256M.
-
Back OT, I would prefer to have a one that has fast 060 with a fast buss, plenty of memory,"loved 128M on my Tek card before it died" and SATA. I'll take 1 for my A2000 & A4000T.
PS: the 4KT really should have 256M.
Yes that's what I was saying earlier on this thread.
Obviously the Classic HW market is small these days but a single FPGA card design could be adapted for all Classic Amiga's without too much effort. If such a card was priced competitively then it could be worth it.
-
I fully agree. But more will come in time. Easy stuff funds harder stuff, etc.
Chris
PS:Actually I should have said "at least 256M".
And to settle the issue, What 68K Amiga can have more than 8Meg on the bus? none, must be on 68030 accell board or better!
-
Ok, I drink the cool aid and accept that all 68000 systems are 16/32bit and also jump around happily that someone is working hard to give us 64bit execution capable m68k!! Seriously, this announcement is HUGE, it should have its own story!! :banana: :banana:
-
Ok, I drink the cool aid and accept that all 68000 systems are 16/32bit and also jump around happily that someone is working hard to give us 64bit execution capable m68k!! Seriously, this announcement is HUGE, it should have its own story!! :banana: :banana:
Well 68000 did have 32bit instructions
This operations "32bit-val" + "32bit-val" = "32bit-val" could be done with a single instruction.
So by this definition the 68000 was a 32bit CPU.
Also the registers of the 68000 are 32bit wide.
Having 32bit wide registers also would make it a 32bit CPU.
Later 680x0 CPU did then instructions faster.
This chart shows very nicely the improvement over time.
http://www.apollo-core.com/bringup/minibench.pdf
While the 68030 was running AMIGA OS ver fast
You see very nicely how "weak" the 68030 design was compared with an 68040 or compared with the 68060.
For example doing this instruction:
ADD.l #$1234567,D0
The 68030 @ 25 MHz only reached about 4 Mips
The 68040 @ 25 Mhz reaches about 23 Mips
You see here clearly how the CPU was internally improved.
The 68060 if running @ 25 MHz would have reached 15 Mips here.
The 68060 was clearly the best 68K core but its design also had some weak spots.
Phoenix in the Vampire1 @ 25 MHz would reach 21 Mips
Phoenix underperforms here a little as we had to cut of an arm and a leg to make it fit the Vampitre1.
Phoenix in the Vampire2 @ 25 Mhz does reach 42 Mips
See see here clearly the evolution of the cores..
If you compare the 4 Mips of the 68030 with the 42 Mips of Phoenix you see that at the same clockrate the improved internal CPU architecture gives a 10 times speed up.
I think this example shows again how pointles comparing a Core by the clockrate is.
Of course a lot more then 25MHz can be reached....
I wonder if "grading" the core releases by their minibench scores would make sense.
Or maybe introducing a virtual clockrate like "performaning like a 68030 @ 400 MHz" would be usefull?
-
this card we are talking about here has been developed and built at home by someone who actually learned how to do that. it is a firstling project. the documentation has been open sourced afaik, other people build it and everybody not satisfied with it can modify and produce it to his content. from the hardware point of view, it has never been designed for the speed it is reaching now. the original developer had a lot of hassle to achieve 68030 class of performance. now, as gunnar says there is a lot devices out there with less potential but a higher price and funny enough not just everybody is complaining about that. not long ago the general public and serious developers around even considered this a hoax.
sure thing, having 2 gig ram would be cool one day. but even using multiple tabs in owb on aros68k you can surf a while with 128 or 64mb. you should not compare 68k to ppc, which usually needs up to two times the ram for the same task.
so as this card is readily available, and in hands of people i think it is only right to tune it to the limit and develop and test the core in it, for the time being, while another hardware is on its way. i wonder whats so wrong with it.
-
+1 to what you say wawrzon.
That said, I think everyone appriciate the card being presented. But, again, people start talking about what they dream about, they tend to forget the practicality of it.
-
might be worth to add that a600 being most compact device of amiga family has never been designed for much expandability and deserves such a compact card well. it was a good choice for a startup project. experience gathered will surely benefit eventual future solutions to fit in more advanced machines.
-
CD32 is even more compact and features a real connector :)
-
Biggun: so how about that "64bit execution" thing? Or as I understand it, 64bit address space to break the 32bit memory barrier of AmigaOS. It sounds cool, but only usable for emulators so far, no m68k hardware is even close to reach that limit.
Personally I would say the way forward is to get rid of legacy hardware alltogether, and design new FPGA based motherboards like FPGA Arcade Replay and MiST, and why not with connectors for real Amiga keyboards so people can build them into A500, A600 and A1200 cases.
-
CD32 is even more compact and features a real connector :)
it has no built in keyboard!
-
Biggun: so how about that "64bit execution" thing?/QUOTE]
Don't get me wrong. I did not say that 64bit is mandatory for AMIGA OS.
It was just that someone said 68K Cores can not be 64bit ever.
And this is not true - technically it takes me only little effort ot make the CPU 64bit.
-
But then it would no longer be m68k, would it? :)
-
it has no built in keyboard!
But it has keyboard connector on the side.
-
it has no built in keyboard!
Neither does an A1000, A2000, A3000 or A4000.
-
Neither does an A1000, A2000, A3000 or A4000.
yes, do you understand what "compact" may mean?
-
yes, do you understand what "compact" may mean?
Compact like this?
(http://www.geeky-gadgets.com/wp-content/uploads/2009/02/small-usb-keyboard_3.jpg)
-
can we return to topic? it was only a remark on my part, i see it would take pages to explain it so lets just forget this.
-
But then it would no longer be m68k, would it? :)
Why not?
Sometimes people ask some funny questions..
-
Why not?
Sometimes people ask some funny questions..
I've occasionally wondered what the 680x0 might have become if it had achieved the same sort of popularity as the x86. The latter had a lot more severe obstacles to overcome with respect to the horrible ISA, historical transitions of the architecture from 16 bit to 32, then 64, not to mention things like virtualization. Yet it managed to succeed thanks to lots of money and skilled engineers working around said train wrecks.
The 680x0 is unarguably a superior architecture than the x86 was when considering forwards compatibility. 32 bit registers from day 1, virtualization issues resolved by the 68010, sensible instruction layout, good fpu integration (the x87 is a nightmare in comparison). Imagine what the same reservoir of cash and talent could have accomplished with it.
It's not hard to imagine the registers growing to 64 bit, a few new instructions for 64 bit wide operations and additional SIMD extensions being added for multimedia.
Meanwhile, in reality...
-
I've occasionally wondered what the 680x0 might have become if it had achieved the same sort of popularity as the x86. The latter had a lot more severe obstacles to overcome with respect to the horrible ISA, historical transitions of the architecture from 16 bit to 32, then 64, not to mention things like virtualization. Yet it managed to succeed thanks to lots of money and skilled engineers working around said train wrecks.
The 680x0 is unarguably a superior architecture than the x86 was when considering forwards compatibility. 32 bit registers from day 1, virtualization issues resolved by the 68010, sensible instruction layout, good fpu integration (the x87 is a nightmare in comparison). Imagine what the same reservoir of cash and talent could have accomplished with it.
It's not hard to imagine the registers growing to 64 bit, a few new instructions for 64 bit wide operations and additional SIMD extensions being added for multimedia.
Meanwhile, in reality...
Yes in fact, Phoenix does touch many of these areas already.
A number of improvements are in Phoenix
* some address mode restrictions removed
* more work registers
* fully pipelined FPU
* We even have developed a Vector Unit ...
-
please continue your fantastic work I want this board.
-
can we return to topic? it was only a remark on my part, i see it would take pages to explain it so lets just forget this.
Sorry, I was just playing, and of course I really want a nice little expansion for my CD32.
-
How come nobody is seeing this card is a revolution started by Majsta. It is the best thing happened to AMIGA since AGA. A card that will be affordable and will outperform anything available thanks to majsta, biggun and the rest of talented people. Majsta started the revolution in Amiga hw and made it open source so all of you haters and demanders can make your own version and add 100GB of fast ram and 200GB of chip ram so you can open 1000 tabs in an non existing browser for 68k.
I salute Majsta and biggun and wish them all the best in their work and if they decide to make the card 8MB i will buy it.
-
If you are going to the next step in 68k. How much of a speed boost would you get by adding more math units on the chip?
-
How long is a piece of string?
Seriously, that's so vague as to be unanswerable. Im not sure you even truly understand what youre asking, or else you'd have asked a question that can be answered in a way other than "how long is a piece of string" :-)
Maths units? Interger or floating point? Also, just adding extras doesn't automatically make it faster.
-
He may have a point. I don't think a 68K Amiga can ever use a good GPU, some extra math units maybe helpful.
-
Again, simply saying "maths unit" is vague to a point of it not really meaning much.
I assume it's meant to be floating point units, but that's not what has been said.
Also, *any* gpu will help a 68k cpu. Voodoo3, radeon 9200, heck even s3 virge.
There's little point in adding anything better than whats available anyway. GPU's need cpu grunt to get the most from them. Adding support for anything faster will add pretty much nothing.
It's amazing how many people are under the impression that a gpu is enough. It's not. It needs cpu grunt to get the most from a gpu.
For example, running a 5ghz i7 + radeon hd 5850 is often faster (especially for minimum framerate) than a 3.4ghz i7 + crossfire 7970's.
-
* some address mode restrictions removed
While I'm all for the Phoenix, this is an "improvement" I do not agree with. There are reasons for these "restrictions" all along, and Mot made a choice with these restrictions. The reason why d(PC) and d(PC,Xn) is read-only is a good one: Everything that these two ea's can address is in the "text segment", also known as "code". "code is not supposed to be modified", this is what Motorola expresses here clearly. If you want data, put that into a data segment and address it either absolute or relative to a segment pointer (aka a4). One should not forget that the Motorola FPUs have an external address space that is larger than 32 bit. It is 32+3 bit, 32 address bits plus three "function code bits". Whether these have been used in the Amiga is another question, but as far as the CPU architecture is concerned, this is very consistent with the "restrictions" of the addressing modes. d(PC) is a "instruction space access" and hence read-only, as all instruction space accesses. d(an) is a data access, and hence has a function code identifying data accesses, and hence is read-write. I would pretty much prefer to keep this clean model, no matter whether it is actually enforced in the Amiga or not.
-
Mot made a choice with these restrictions. The reason why d(PC) and d(PC,Xn) is read-only is a good one:
Of course I can also see the "idiology" of MOTO behind it.
But lets also look at the reality.
During the project we did disasm so many programs and looked wwhat they do and how well the CPU can do it.
There were many programs programs doing this often and very often
lea (d,pc),A0
addq.l #1,(A0)
So if a programmer or compiler decided to update local variables in such a way
and does this 1000 times in his program - then so be it.
With the old address limitations he can still do it. But the programs executed 1000 instructions more, and is 2024 Byte bigger.
-
As far as I know an 040 and 060 has a single branch to execute floating point operations. If you had three branches or more would you get some seriously fast math operations. If not what would limit it?
-
As far as I know an 040 and 060 has a single branch to execute floating point operations. If you had three branches or more would you get some seriously fast math operations. If not what would limit it?
68060 FPU was not pipelined and most instructions took at least 3 cycles.
Phoenix FPU is fully pipelined and can do a 80bit FMUL every clock cycle.
This means clock by clock the Phoenix FPU is already 3 times faster than an 68060.
This means a 100 Mhz Phoenix is FPU wise in theory as strong as an 68060 @ 300 MHz
-
While I'm all for the Phoenix, this is an "improvement" I do not agree with. There are reasons for these "restrictions" all along, and Mot made a choice with these restrictions. The reason why d(PC) and d(PC,Xn) is read-only is a good one: Everything that these two ea's can address is in the "text segment", also known as "code". "code is not supposed to be modified", this is what Motorola expresses here clearly. If you want data, put that into a data segment and address it either absolute or relative to a segment pointer (aka a4). One should not forget that the Motorola FPUs have an external address space that is larger than 32 bit. It is 32+3 bit, 32 address bits plus three "function code bits". Whether these have been used in the Amiga is another question, but as far as the CPU architecture is concerned, this is very consistent with the "restrictions" of the addressing modes. d(PC) is a "instruction space access" and hence read-only, as all instruction space accesses. d(an) is a data access, and hence has a function code identifying data accesses, and hence is read-write. I would pretty much prefer to keep this clean model, no matter whether it is actually enforced in the Amiga or not.
Were you not invited to the Apollo Forum before the ISA decisions were made? Your name was mentioned in the ISA discussions and someone even put words in your mouth in your absence. If you are worried about such a minor issue as "PC" relative writes then maybe you should have a look at the lack of orthogonality necessary to add more registers, of which there are now 4 types and one of which is called A8. I was willing to compromise on "PC" relative addressing as I consider it a minor issue that is inadequate for code protection and it would help code density to a very minor degree (I did not draw the same conclusions from analyzing dissassembled code not that it is the first time or that I even bother mentioning such things any more). Maybe you would have had been given enough respect and been able to argue your issues enough in the ISA committee to make a difference but I doubt it. The committee of one has already decided the future of the 68k. I'm sorry you wern't there and missed your oppurtunity. Oh wait, never mind, this is somebody's toy project and the committee dissolved for lack of "yes" men.
-
Matthey,
the amount of "voting" to the project is in level to their work contributed.
There are some people who have contributed some hundred thousand lines and some which have not.
-
Were you not invited to the Apollo Forum before the ISA decisions were made? Your name was mentioned in the ISA discussions and someone even put words in your mouth in your absence. If you are worried about such a minor issue as "PC" relative writes then maybe you should have a look at the lack of orthogonality necessary to add more registers, of which there are now 4 types and one of which is called A8. I was willing to compromise on "PC" relative addressing as I consider it a minor issue that is inadequate for code protection and it would help code density to a very minor degree (I did not draw the same conclusions from analyzing dissassembled code not that it is the first time or that I even bother mentioning such things any more). Maybe you would have had been given enough respect and been able to argue your issues enough in the ISA committee to make a difference but I doubt it. The committee of one has already decided the future of the 68k. I'm sorry you wern't there and missed your oppurtunity. Oh wait, never mind, this is somebody's toy project and the committee dissolved for lack of "yes" men.
I am a little disappointed of your behavior
-
@olaf
Why? Matt is helpful, constructive and concerned person. Mentioning doubths in the open isnt wrong.
-
@olaf
Why? Matt is helpful, constructive and concerned person. Mentioning doubths in the open isnt wrong.
The situation is that hardware developers which do _all_ the development work on the core
and which have CPU design and FPGA know-how have certain opinions
what features should be implemented, and which features are sensible to do in an FPGA.
People from the outside can voice their opinions this is OK.
Its also OK that they voice their opinion if they have no FPGA knowledge.
But the decision of what gets implemented is done by those who do the work.
-
Matthey,
the amount of "voting" to the project is in level to their work contributed.
There are some people who have contributed some hundred thousand lines and some which have not.
Then ThoR would have had no vote either and I was correct about it being someone's toy project.
I am a little disappointed of your behavior
I have never been someone's "yes" man but instead have had my own opinions which I have not hidden. I hope the Phoenix project is successful but I believe that the "enhancements" are missing the mark as far as being adopted and used as a 68k Amiga standard (something you want Olaf). Also, better ColdFire support would have made adoption and support easier outside of the Amiga community and made an ASIC for combined embedded use more likely. The enhancements are driven by one persons insatiable desire for more registers and performance at any cost, including future planning. Yes, he has done most of the work so perhaps it is his decision for his pet project. No one is stopping him or being rude but it does leave open Karlos's pondering, "I've occasionally wondered what the 680x0 might have become if it had achieved the same sort of popularity as the x86." We may never know what a professional company would have done instead of a pet project driven by one man's desires. I shouldn't complain as at least we get a faster 68020 compatible CPU but neither can I sell the enhancements I do not believe in.
-
@matt
Two matters that make things a bit less scary:
1. Fpga isnt set in stone hardware, it might be reprogrammed and adjusted according to the reaction it meets. Reacting to the feedback would be wise on part of developers. But there always will be different opinions, thats sure.
2. Any extensions beyond what the legacy 68k provides will not have much effect until compiler backends will assimilate these extensions. Which will not happen any soon, giving time to reconsider. The legacy instruction set and its execution efficiencyis what counts atm.
-
Then ThoR would have had no vote either
Of course Thomas Richter has a vote. :-)
Thomas did contribute to the project and we value his opinion.
At the end the people doing the work will make the decision. I think this is normal.
And as MP3 playback and DOOM and other programs show..
The software Compatibility and Performance are good.
In fact the performance of Poenix is better than any 68K CPU was ever before.
-
@matt
Two matters that make things a bit less scary:
1. Fpga isnt set in stone hardware, it might be reprogrammed and adjusted according to the reaction it meets. Reacting to the feedback would be wise on part of developers. But there always will be different opinions, thats sure.
Yes, this is true. Phil "meynaf" also did not like the direction of the new ISA but challenged for it to be created as a test. It is possible to learn from doing things the hard way. The few people that write code for the new ISA would be disappointed if the ISA changed significantly. The new ISA is unlikely to be (even partially) adopted in the TG68 or other 68k fpga cores or eventually UAE (I believe Toni's position would change if multiple fpga hardware was using the same ISA) . It is less likely that a non-standard complex 68k ISA for a single fpga CPU would gain wide spread support in compilers. A core which is more compatible with both 68k and ColdFire is more likely to be interesting to embedded developers. Enough money could probably gain a custom ISA and then we could have a thousand variations of an ISA like ARM but this is what I hoped to avoid. People thought I was too early trying to push for the creation of a standarized ISA and trying to get input from others. I tried to create a standards committee/group by bringing in people to our discussions including inviting ThoR, Frank Wille and Dave Alsup (of Innovasic). I would have loved to bring in people like Tony Wilen, Jason McMullan, Volker Barthelman, Kalms and maybe even a Karlos who have understanding of an ISA from different view points. I guess people are too busy or believe the Amiga is too dead to care anymore. At least Gunnar is doing something.
2. Any extensions beyond what the legacy 68k provides will not have much effect until compiler backends will assimilate these extensions. Which will not happen any soon, giving time to reconsider. The legacy instruction set and its execution efficiency is what counts atm.
ISA decisions make a big difference in how easily and quickly the ISA changes can be adopted. ColdFire enhancements are the easiest to adopt because they already exist and only need to be switched on in a compiler backend and in peephole optimizing assemblers. I bet Frank Wille could have ColdFire support in vasm working in a few days and already making a noticable difference in shrinking program sizes. ColdFire support in the backend could take a few weeks to add and test as it is a more delicate process to add. Taking advantage of the current ISA with more registers in the backend would likely take many months and bugs could turn up for years. Few developers are knowledgable and familiar enough with a compiler to add this kind of support. Are they going to dedicate this kind of time for a non-standard in an fpga CPU sold in the hundreds or low thousands at the most when they could be improving a compiler target with tens of thousands of hard processors? I don't think so. Phoenix is not going to immediately set the world on fire. IMO, it's better to have an easy standard to adopt with a few benefits and incremental improvements than a core specific non-standard with theoretical high performance that will never be utilized completely in compilers. Splits seem to be the Amiga way though. I'm tired of arguing and trying to create something better. Gunnar did make the right decision to add better 68020 compatibility (all addressing modes without trapping) and we do have this as a base which is the most important thing. We are moving forward past the 68060 in performance with this too. I should be thankful as we need new 68k hardware to revitalize the Amiga. I would have liked to create something like a cross between an Amiga Raspberry Pi, a Natami and a CD32+ but there is not enough cooperation, at least not yet.
-
Then ThoR would have had no vote either and I was correct about it being someone's toy project.
I have never been someone's "yes" man but instead have had my own opinions which I have not hidden. I hope the Phoenix project is successful but I believe that the "enhancements" are missing the mark as far as being adopted and used as a 68k Amiga standard (something you want Olaf). Also, better ColdFire support would have made adoption and support easier outside of the Amiga community and made an ASIC for combined embedded use more likely. The enhancements are driven by one persons insatiable desire for more registers and performance at any cost, including future planning. Yes, he has done most of the work so perhaps it is his decision for his pet project. No one is stopping him or being rude but it does leave open Karlos's pondering, "I've occasionally wondered what the 680x0 might have become if it had achieved the same sort of popularity as the x86." We may never know what a professional company would have done instead of a pet project driven by one man's desires. I shouldn't complain as at least we get a faster 68020 compatible CPU but neither can I sell the enhancements I do not believe in.
I wrote that not because you disagreed or because of your opinion but because I dislike it when internal discussion are published in public. Internal should stay internal. That is my opinion.
To topic... new features always have the problem that they are not supported as long compilers are not adapted and software not recompiled. But a superfast 68020 compatible processor would be a lot already.
-
Apollo is much bigger than it appears to many.
The project does not only include CPU but also FPU and SIMD features.
A lot of planning and over 5 years of development were put into this project.
The current FPGA cards show a small part of the project.
The upcoming FPGA cards will show a lot more....
-
I wrote that not because you disagreed or because of your opinion but because I dislike it when internal discussion are published in public. Internal should stay internal. That is my opinion.
But the problem was that the ISA discussion was internal and the group too small. There were only 3 people with enough understanding to even have an opinion. Meynaf and I have somewhat similar (overlapping) experience and perspectives. Gunnar's perspective is very different. We did not have a diversified enough or large enough group that a consensus even matters. Gunnar opened up the apollo forum to the public recently so I don't even know what is considered internal discussion,
To topic... new features always have the problem that they are not supported as long compilers are not adapted and software not recompiled. But a superfast 68020 compatible processor would be a lot already.
Phoenix may help the 68k targets of compilers to get some attention, I do not expect any major compiler support beyond that. Do you think the 68020 ISA is modern enough to compete with newer ISAs? Do you think it's modern enough to attract developers?
-
But the problem was that the ISA discussion was internal and the group too small. There were only 3 people with enough understanding to even have an opinion. Meynaf and I have somewhat similar (overlapping) experience and perspectives. Gunnar's perspective is very different. We did not have a diversified enough or large enough group that a consensus even matters. Gunnar opened up the apollo forum to the public recently so I don't even know what is considered internal discussion,
Phoenix may help the 68k targets of compilers to get some attention, I do not expect any major compiler support beyond that. Do you think the 68020 ISA is modern enough to compete with newer ISAs? Do you think it's modern enough to attract developers?
compete with modern ISA´s? You mean X64 or ARM? That is completely unrealistic. How much money and developers are invested in that ISAs and how much time you think Gunnar and the few others can invest in it? We need not to compete with ARM but the best solution for our platform. A good FPGA based device at affordable price has a market but of course not a mass-market at the level of ARM or X64. Or what is your idea? What would the "market" you see?
And we have a lot of compilers already (partly even with source code). We need best support for them. Developers are attracted by modern development environments with modern class libraries. And distribution opportunites (=user base). Not details of the ISA. I am propably typical for that kind of people. I use Visual Studio and Delphi on Windows. I could not care less about the details of the ISA it runs on.
-
compete with modern ISA´s? You mean X64 or ARM? That is completely unrealistic. How much money and developers are invested in that ISAs and how much time you think Gunnar and the few others can invest in it? We need not to compete with ARM but the best solution for our platform. A good FPGA based device at affordable price has a market but of course not a mass-market at the level of ARM or X64. Or what is your idea? What would the "market" you see?
The 68020 ISA is from the late '80s and what we are stuck with if the new ISA is not adopted. The 68k probably doesn't need to compete with x86_64 or ARM (they have more baggage also) but it could use some modernization. I was looking for interest in the embedded "market" where the small memory footprint is an advantage but that was before Gunnar dropped much of the ColdFire compatibility.
And we have a lot of compilers already (partly even with source code). We need best support for them.
I have submitted changes/fixes to the 68k backend of vbcc which I expect is one of the simplest compiler backends. While I was generally successful in getting my changes to work, I was not at all sure of rare side effects that my code could have caused. It would take months of studying the code and working with it before I would feel comfortable in making changed which were not reviewed by Volker. Frank Wille is a more experienced and better programmer than me and he does not make any major changes to vbcc without submitting them to Volker. Compilers are not rocket science but they have intricate sensitive code that requires knowledge and experience to change even with sources.
-
The 68020 ISA is from the late '80s and what we are stuck with if the new ISA is not adopted. The 68k probably doesn't need to compete with x86_64 or ARM (they have more baggage also) but it could use some modernization. I was looking for interest in the embedded "market" where the small memory footprint is an advantage but that was before Gunnar dropped much of the ColdFire compatibility.
I have submitted changes/fixes to the 68k backend of vbcc which I expect is one of the simplest compiler backends. While I was generally successful in getting my changes to work, I was not at all sure of rare side effects that my code could have caused. It would take months of studying the code and working with it before I would feel comfortable in making changed which were not reviewed by Volker. Frank Wille is a more experienced and better programmer than me and he does not make any major changes to vbcc without submitting them to Volker. Compilers are not rocket science but they have intricate sensitive code that requires knowledge and experience to change even with sources.
i think we do not need new super-ISAs but a new platform that support the existing software base. I think (if I remember right) there are about 12 compilers in Aros Vision and not for all are source codes available. Even if it is possible to adapt one or two there would still be most unchanged. Another problem is for many programs source codes are not available so recompiling is unpossible. Developers are not attracted by asm code or ISA features but how easy can they solve their problems. That should be first priority in future,
-
i think we can trust it to take its course for now. that the discussion about the isa took place in small circle has it advantages and disadvantages. but the advantage for now is that it led to results, while even there apparently were differences. on larger forum there might have been a lot of talk that might have led to nothing. now the project is approaching the wider audience, which will be a new situation. lts see what happens.
-
If you look at the evolution of the 680x0 while it was in development, the 68020/882 represents the peak of (non-privileged) 68K instruction complexity. The 040 and 060 focused on streamlining it so that only the most used operations were implemented in silicon.
Now, if you compile code for 020+, a good compiler avoids emitting anything needing traps on 040/060 (of course it can and does happen).
In my humble opinion then, if the FPGA implementation covers the 68040/60 operations (not necessarily every 020/882 operation) then it'll be great just as is. Any extra additions are niceties as it will take time to implement assembler/compiler/debugger tools for them. It's really up to the guys making the hardware. And fair play to them.
-
@karlos
+1
matt has probably another view on the matter as he researched an eventual further evolution of 68k particularly, but there is concept vs implementation, theory vs immediate practice, which may be hard to get agreed upon.
-
If you look at the evolution of the 680x0 while it was in development, the 68020/882 represents the peak of (non-privileged) 68K instruction complexity. The 040 and 060 focused on streamlining it so that only the most used operations were implemented in silicon.
Yes, this is another reason that the 68020+6888x is a poor ISA base target. When we talk of this target we are talking about a simplified version of it but what compilers generate may not be. Motorola went overboard with increasing the complexity of the 68020 and 6888x ISA but then they chopped too much. The removal of the FINT/FINTRZ in the 68040 was a *huge* mistake and the removal of 64 bit integer MUL/DIV from the 68060 was also a poor decision. Modern 32 bit ISAs have these instructions and more. Motorola was attracted to the simplicity of RISC and tried to turn the 68k into an old school simplified RISC processor. Most of the old school RISC processors are gone now (except MIPS and some would say SPARC) while we are left with PPC and ARMv8 which have larger and in some ways more complex instruction sets than the 68k (more operands for example).
I didn't want to bring back all the complexity and mistakes that Motorola removed. The evaluation ISA looked something like this:
http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf
It probably needs some slimming and tuning but there are some very good ideas also. Gunnar decided that more registers was the holy grail of performance and decided to sacrifice nearly everything else. It is possible to increase the number of FPU registers in an orthogonal way as demonstrated in the evaluation ISA above but not so for new integer registers. Compilers have problems with the An/Dn split but now we have 8 non-orthogonal En and an A8 register encoded in any way that could be found. The new Phoenix ISA does get new planar gfx instructions also. I would give a link to the new Phoenix ISA but I haven't seen any documentation yet. That doesn't stop it from being the "standard" as I have seen nothing indicating it is a trial or evaluation ISA.
Now, if you compile code for 020+, a good compiler avoids emitting anything needing traps on 040/060 (of course it can and does happen).
You are correct that most compilers will generate trapped 6888x FPU instructions when compiling for the 68040 and 68060 (but most avoid trapped integer instructions). Vbcc should not generate any 6888x FPU instructions when compiling for the 68060 and linking with -lm060. If it does or you have any other problems with the direct FPU libs then let me know and I'll fix it (details here):
http://eab.abime.net/showthread.php?t=74692
In my humble opinion then, if the FPGA implementation covers the 68040/60 operations (not necessarily every 020/882 operation) then it'll be great just as is. Any extra additions are niceties as it will take time to implement assembler/compiler/debugger tools for them. It's really up to the guys making the hardware. And fair play to them.
Sure, it is up to the hardware guys. It is "fair play" for them to make their own standards, sell out, move on, fail and quit also. Business is business and hope is fleeting.
-
That might be fine for a CPU, but FPGAs are designed differently and may not get an advantage from CPU improvements.
-
To really interested I'm happy to explain the advantages
and reasons behind certains ISA differences.
Also in the context of what is possible or of advantage in an FPGA versus ASIC design.
And also in the context of what considerations or differences todays cache or memory interfaces have.
I think there here might not be the ideal place for explaining this.
If someone is _really_ interested in learning about this, brainstomring or discussing this topic,
then I invite you to go to the forum on http://www.apollo-core.com. I'm happy to give explanantion, data, and real live measurements for you there.
-
Let's not get too caught up in the specifics, it's very impressive stuff :)
The future in Classic hardware is FPGA!
-
Yes, this is true. Phil "meynaf" also did not like the direction of the new ISA but challenged for it to be created as a test. It is possible to learn from doing things the hard way. The few people that write code for the new ISA would be disappointed if the ISA changed significantly. The new ISA is unlikely to be (even partially) adopted in the TG68 or other 68k fpga cores or eventually UAE (I believe Toni's position would change if multiple fpga hardware was using the same ISA) . It is less likely that a non-standard complex 68k ISA for a single fpga CPU would gain wide spread support in compilers. A core which is more compatible with both 68k and ColdFire is more likely to be interesting to embedded developers. Enough money could probably gain a custom ISA and then we could have a thousand variations of an ISA like ARM but this is what I hoped to avoid. People thought I was too early trying to push for the creation of a standarized ISA and trying to get input from others. I tried to create a standards committee/group by bringing in people to our discussions including inviting ThoR, Frank Wille and Dave Alsup (of Innovasic). I would have loved to bring in people like Tony Wilen, Jason McMullan, Volker Barthelman, Kalms and maybe even a Karlos who have understanding of an ISA from different view points. I guess people are too busy or believe the Amiga is too dead to care anymore. At least Gunnar is doing something.
ISA decisions make a big difference in how easily and quickly the ISA changes can be adopted. ColdFire enhancements are the easiest to adopt because they already exist and only need to be switched on in a compiler backend and in peephole optimizing assemblers. I bet Frank Wille could have ColdFire support in vasm working in a few days and already making a noticable difference in shrinking program sizes. ColdFire support in the backend could take a few weeks to add and test as it is a more delicate process to add. Taking advantage of the current ISA with more registers in the backend would likely take many months and bugs could turn up for years. Few developers are knowledgable and familiar enough with a compiler to add this kind of support. Are they going to dedicate this kind of time for a non-standard in an fpga CPU sold in the hundreds or low thousands at the most when they could be improving a compiler target with tens of thousands of hard processors? I don't think so. Phoenix is not going to immediately set the world on fire. IMO, it's better to have an easy standard to adopt with a few benefits and incremental improvements than a core specific non-standard with theoretical high performance that will never be utilized completely in compilers. Splits seem to be the Amiga way though. I'm tired of arguing and trying to create something better. Gunnar did make the right decision to add better 68020 compatibility (all addressing modes without trapping) and we do have this as a base which is the most important thing. We are moving forward past the 68060 in performance with this too. I should be thankful as we need new 68k hardware to revitalize the Amiga. I would have liked to create something like a cross between an Amiga Raspberry Pi, a Natami and a CD32+ but there is not enough cooperation, at least not yet.
You have not yet answered what you see as "market". And perhaps you could be wrong too, there can be more than one true. If I understood you right you preferred different choices because of it would be better for ASIC implementations whereas Gunnars design is better for FPGA (I hope I recalled it correctly) and you wanted to sell the core outside to other companies. To say it clear if today somebody needs power he uses X64 and if somebody wants something for mobile/embedded he will take ARM. There is not much room for other ISAs so to make a design that is not perfect running on FPGA (=fastest possible) just because it might perhaps be used outside is simply waste of resources. We need BEST solution for the Amiga platform. There are years of development in the project and I trust Gunnar that they made wise decisions when they worked at it.
BTW as I said most developers do not care about ISA details or certain instructions, that is a much too technical discussions not related to reality. How many 68k hardcore coders are still there? I know Novacoder and then I must think. Propably one hand is enough to count them. Even hobby developers are using compilers, that is even more true for commercial developers. Most people do not hack on the hardware anymore or program in asm. I had contacted former amiga developers because I thought I might create some interest again. Unfortunately that was not the case. So we have to build upon what we have, existing software and existing compilers. Anything else is unrealistic.
-
That might be fine for a CPU, but FPGAs are designed differently and may not get an advantage from CPU improvements.
Hard processors are designed in FPGAs first (some of the Amiga custom chips were designed in FPGA too). There are some differences but functionally they are very similar. Some ISA improvements only make sense in a hard CPU or ASIC because of limitations of muxes and clock speeds in an FPGA. Most simple changes which reduce the number of instructions, reduce the code size, add new instructions with new functionality, add new addressing modes, add registers, etc. will be of benefit to the CPU. Adding complexity (usually too many muxes) in some critical areas of the fpga CPU would slow down the core clock speed.
You have not yet answered what you see as "market". And perhaps you could be wrong too, there can be more than one true. If I understood you right you preferred different choices because of it would be better for ASIC implementations whereas Gunnars design is better for FPGA (I hope I recalled it correctly) and you wanted to sell the core outside to other companies. To say it clear if today somebody needs power he uses X64 and if somebody wants something for mobile/embedded he will take ARM. There is not much room for other ISAs so to make a design that is not perfect running on FPGA (=fastest possible) just because it might perhaps be used outside is simply waste of resources. We need BEST solution for the Amiga platform. There are years of development in the project and I trust Gunnar that they made wise decisions when they worked at it.
I see a potential market for the Amiga but it needs to be built up and probably requires investment to get it back on its feet (Trevor@A-EON understands but misses that the 68k has more potential for the masses than PPC). Piggy backing on and cooperating with embedded projects and businesses could reduce the investment needed (economies of scale are especially killer for low production hardware). Yes, I did contact some embedded businesses. Yes, it is tough to compete against mature ARM processors and ARM is the best solution for super low power consumption embedded targets. An enhanced 68k has clear advantages over ARM with Thumb 2 for more powerful embedded (and computing) uses which includes:
1) easier to use
2) lower memory requirements (better code density)
3) more powerful addressing modes
4) stronger in memory without OoO
5) stronger single core performance without OoO
Adding OoO to ARM substantially increases power consumption perhaps to the level that an in-order superscalar CPU would use. Phoenix (and even the 68060 which is also in-order superscalar) outperforms practically all non-OoO ARM processors in integer performance clock for clock. This should scale to higher clock speeds (most code is executed from the cache where the 68k can fit a little more code). Gunnar can't see an ASIC in the future so he tries to adapt Phoenix (ISA and internal fpga optimizations) for maximum speed at all cost. He adds registers which does increase theoretical performance but requires complex changes to compilers that are unlikely to be implemented. Problems with his ISA changes:
1) haphazard, non-orthogal register additions make the 68k less easy to use and less consistent
2) unlikely to be implemented in a compiler backend
3) loses the advantages of simpler enhancements that could be implemented quickly in compilers
4) sacrifice of ColdFire compatibility limits oppurtunities for embedded use
5) less likely to be made into an ASIC
6) unlikely to be adopted as an Amiga or 68k standard in other cores and emulators
7) radical changes are less likely to be accepted by the conservative 68k loving community
BTW as I said most developers do not care about ISA details or certain instructions, that is a much too technical discussions not related to reality. How many 68k hardcore coders are still there? I know Novacoder and then I must think. Propably one hand is enough to count them. Even hobby developers are using compilers, that is even more true for commercial developers. Most people do not hack on the hardware anymore or program in asm. I had contacted former amiga developers because I thought I might create some interest again. Unfortunately that was not the case. So we have to build upon what we have, existing software and existing compilers. Anything else is unrealistic.
High level programmers don't deal with the abstracted ISA but it is important to how optimized and how much code is produced by the compiler. The key is to making the compiler programmer's life easier not more difficult but bone headed hardware guys are more worried about theoretical performance instead and keep repeating the same mistakes. The ISA shouldn't even be set in stone until after the compiler programmers (and assembler programmers) have attempted using what is new. You are a programmer so maybe you need to try some low level programming to appreciate the ISA. The source for vbcc is here:
http://www.ibaug.de/vbcc/vbcc.tar.gz
The 68k backend is in machines/m68k. Documentation for writing a backend is in the vbcc manual:
http://www.ibaug.de/vbcc/doc/vbcc.pdf
This is probably the simplest and easiest C backend you will find. Once you have some experience making use of Gunnar's "extra registers", you can help with the more challenging GCC and LLVM backends. I'm sure you will have a different opinion about the ISA after a few months and probably before you make any significant changes. Now if we could just get car engineers to be the mechanics for the cars they design for a few months then we would have much better designed cars which are easier to work on too ;).
-
Hmm, I guess "Cool Demo" no longer applies to this thread...
-
Hmm, I guess "Cool Demo" no longer applies to this thread...
At least it's not just full of trolling anymore. ;) This is some pretty interesting stuff, most of it over my head though! :lol:
-
Since we are Way Off Topic:
What we need is a list of topics that brings all the trolls out, like "sucker bait" so we can get our Wack a Mole mallet fix in one fell swoop.
-
@danbeaver
"we" are not ot, its currently you who tries to derail the thread.
-
@biggun
Bloody brilliant! Keep going! ;)
-
Then CD32 is also not a 32bit console, and no m68k Amiga ever, for that matter.
Reading this thread, I remember why so many people have left Amiga.org, and also why many people give up on their personal Amiga hardware projects.
The A600 is a 32-bit computer (native register size) with 24-bit addressing (16MB), and a 16-bit ALU and data bus.
As this argument is all about addressing gigabytes of memory, then we have to take the addressing aspect. 24-bit. That's not 32-bit. End of story. You need to replace the main CPU in the A600 with one that has 32-bit addressing to get that capability.
And yes, this goes for the A1200 and CD32 as well, because they only have a 24-bit address bus on their CPUs. However the data bus is 32-bit, and the ALU is 32-bit, as well as the native 32-bit registers, so we can call the CD32 a 32-bit system, especially since it came out at a time when games consoles came with very little memory (the 2MB the CD32 was massive). Yet you could upgrade the CPU to get a full 32-bit address bus.
The A3000 or A4000 sed '030 and '040 CPUs with a 32-bit address bus from the beginning.
Anyway, the Vampire 600 is an amazing achievement (even with the old core, never mind the new core), and I think it is rude and unrealistic for people to expect it to have 2GB, and that because it doesn't it is somehow rubbish or sub-par.
-
The A600 is a 32-bit computer (native register size) with 24-bit addressing (16MB), and a 16-bit ALU and data bus.
Watch that heresy, someone might come along and call you a dumbass for it! :lol:
-
Haha.
Anyway, regardless of the New-ISA discussions, the main point is that there is something out there working today that works with the majority (all) the 68k Amiga code base, and does it very well, and that there is a new, generic board that should be even faster and expandable (and I'm sure we'll see a video of Quake on an A500 at some point).
-
Hattig's respons was perfectly fine, he confirmed that A600 is a 32bit computer, and that if you let "default CPU" dictate, then neither CD32 nor A1200 are fully 32bit either. Which was exactly the point. As long as you work with CBM Amiga computers and AmigaOS as we know it, then 32bit is your limiting factor for memory addressing.
-
then neither CD32 nor A1200 are fully 32bit either. Which was exactly the point
Which was exactly *my* point. Thankyouverymuch for finally drinking the Kool-Aid.
Sincerely,
Jim Jones
;)
-
guys, could you quit this nitpicking? the actual subject is much more interesting and constructive, also the isa discussion.
-
The A600 is a 32-bit computer (native register size) with 24-bit addressing (16MB), and a 16-bit ALU and data bus.
As this argument is all about addressing gigabytes of memory, then we have to take the addressing aspect. 24-bit. That's not 32-bit. End of story. You need to replace the main CPU in the A600 with one that has 32-bit addressing to get that capability.
Here is the A600's main CPU replaced with the Vampire 600 Accelerator:
(Apollo mini) Phoenix Core BETA v.1996 (https://www.dropbox.com/s/sn7btk4d7z8le79/apollo_mini_1996.mp4?dl=0)
-
Which was exactly *my* point. Thankyouverymuch for finally drinking the Kool-Aid.
Soap box time.
The problem is that the definition of "bitness" has changed over time. Today, it's pretty much the logical address / pointer size. Nobody really cares what the ALU and maximum integer operand size is, though in any architecture with general purpose registers (ie can be a pointer or integer) they tend to be the same width for obvious reasons.
In the early 80s, it was all about the ALU register / data bus size. 8-bit CPUs had 8 bit registers and did operations 8 bits at a time and performed 8-bit data transfers to/from memory/io.
However, every one of them that springs immediately to mind could use a pair of 8-bit register to define a 16-bit address. Most could even perform 16-bit register pair manipulation, for example incrementing or decrementing a whole 16-bit address at once. However, nobody ever considered them as anything other than strictly 8-bit.
In the 16-bit era, this paradigm was largely unchanged but architectures were starting to vary significantly. Some kept the 8-bit model of using pairs of registers to represent an address but individual registers, the ALU and data bus were still 16-bit.
Others, like our much loved 680x0 took a much longer term view. The 68000 had 32-bit wide registers for address and data. The ALU still worked on 16-bit halves at a time, transferred data 16 bits at a time and missed some 32-bit operations (32x32 multiply for example). However, it could still do the majority of 32-bit operations directly in hardware.
We called it 16-bit for want of a better description. It fit because of the data bus width/alignment but it didn't fit the internal register model nearly as well.
Under the current logical address/pointer size definition, it's definitely 32-bit. Nobody gives a rat's bumhole that it only had 24 of the 32 address bits exposed to the outside, neither did many early 32-bit processors or 64-bit ones. Physical connectivity is an implementation detail, especially when considering an architecture as a whole and not just a given chip in the family.
The 68020 is more clearly 32-bit in that it's ALU and data bus are 32-bit, but the EC version still has only 24 address bits exposed. The 32-bit era is where ALU and logical address size were really matched for the first time for almost all architectures. And that's where the "bitness" definition began to change to the present one. There were machines with 64-bit data / ALU but they didn't break the 32-bit logical address space. I guess the 4GiB limit became the new envelope to push against as processors were getting fast enough at crunching data but couldn't easily work on large enough sets of it.
Whether the 68000 is 16 or 32-bit simply depends on which decade's thinking you look at it from.
-
Whether the 68000 is 16 or 32-bit simply depends on which decade's thinking you look at it from.
The 68000 is a 16/32 bit hybrid (more 16 bit) and the 68020 is full 32 bits in my eyes. What is important is that the ISA was forward thinking enough to allow for 32 bit programs from the beginnning. Programs >64kB become less optimal with the 68000 ISA but programs that that were 32 bit clean with their pointers still work today. No memory bank switching or base registers are needed like most 16 bit processors. It's software that matters and good ISAs ;).
-
The 68000 is a 16/32 bit hybrid (more 16 bit) and the 68020 is full 32 bits in my eyes.
I'd say that's late 80's view. Atari would have agreed, they marketed their 68000 machines in those terms.
It's software that matters and good ISAs ;).
Quite. And this is why I don't share what I take to be your pessimism (sorry if I've misinterpreted your objection) to Gunnar's augmentation to the 680x0.
The reason being that if he adds super awesome vector unit X and relaxes various existing restrictions, it won't make any difference to the corpus of existing software. As long as his implementation is compatible with existing object code and is faster than existing 68K solutions then I believe he's got the formula right. Most folks, myself included, want an affordable, performant accelerator card. I missed out on a good 68060 card when they were being sold originally and now they are like rocking horse poop with a price to match. Anything faster than my 040 is a result for me.
That said, I believe you are right to want some steering on any chages to the ISA. I am optimistic that this can happen simply because anything new requires software to be written for it. And unless he aims to write it himself then cooperation with software guys is inevitable. I'm sure he wants any augmentation to be genuinely useful
-
Quite. And this is why I don't share what I take to be your pessimism (sorry if I've misinterpreted your objection) to Gunnar's augmentation to the 680x0.
The reason being that if he adds super awesome vector unit X and relaxes various existing restrictions, it won't make any difference to the corpus of existing software. As long as his implementation is compatible with existing object code and is faster than existing 68K solutions then I believe he's got the formula right. Most folks, myself included, want an affordable, performant accelerator card. I missed out on a good 68060 card when they were being sold originally and now they are like rocking horse poop with a price to match. Anything faster than my 040 is a result for me.
I supported doubling the number of FPU registers (I came up with 99% compatible 6888x compatible encodings) as it can be done in a consistent and orthogonal way. More than 2 scratch FPU registers is a big advantage so no FMOVEM is needed for 8 new scratch FPU registers (An updated ABI would be advantageus though). I support adding a vector unit with many vector registers. I don't support combining the integer unit(s) and vector units while adding non-orthogonal and larger integer/vector registers in whatever encoding whole can be found with whatever limitations from what can't be supported, Maximum FPGA optimization involves combining units but this is a bad idea as it becomes more complex and an ASIC becomes less likely. The ISA would only be usable by ultra-optimized 68k like FPGA cores (of which there will be only one) and the 68k ease of use will become like a DSP with all the funky registers (take a look at the StarCore DSP ISA for example). I would be very surprised if a compiler tries to take advantage of the extra vector/integer hybrid whatever registers and 68k assembler fans are likely to turn up their nose also, Gunnar's new ISA is like trying to force a square peg through a round hole but he has decided that the square peg is better and that he will have it at all costs.
That said, I believe you are right to want some steering on any changes to the ISA. I am optimistic that this can happen simply because anything new requires software to be written for it. And unless he aims to write it himself then cooperation with software guys is inevitable. I'm sure he wants any augmentation to be genuinely useful
Sure. Change and cooperation happen quickly in the Amiga realm. Maybe he will give up on his ISA in a few years after no compilers implement it but then he is mighty proud of it. Maybe Hyperion will eventually see the light of cooperating with the 68k Amiga masses before they go broke too.
-
Maximum FPGA optimization involves combining units but this is a bad idea as it becomes more complex and an ASIC becomes less likely.
interesting interesting.
You are aware that the people who have developed the APOLLO work as professionally FPGA and CPU designer, don't you?
You know that some of IBM fastest Accelerators and latest POWER chips were desinged by those people.
-
You are aware that the people who have developed the APOLLO work as professionally FPGA and CPU designer, don't you?
You know that some of IBM fastest Accelerators and latest POWER chips were desinged by those people.
Your time would be better spent writing up your ISA and submitting it to the GCC and LLVM maintainers along with your credentials. Olaf is the only one here who might make a backend with your ISA and he already knows your credentials.
-
@ Matthey
Could you tell us why you need an ASIC so badly? There is only one coldfire accelerator card for an Atari.
Seriously a $50 ras pi, must be a better choice for embedded systems. I don't feel a sudden need to control something from AmigaOS
-
@ Matthey
Could you tell us why you need an ASIC so badly? There is only one coldfire accelerator card for an Atari.
This is all bollocks spread by one person.
There is nothing technically in APOLLO which prevents doing an ASIC.
-
There is nothing technically in APOLLO which prevents doing an ASIC.
I dont think anyone disputes that. The implication was just that it is less likely if we dont engage with, and make it attractive to, the types of people who could afford to build one with us.
-
The implication was ....
Facts are:
* Phoenix is working,
* People use it
* Phoenix is the most technical advanced and fastest 68K CPU ever done by men. :-)
I find this "barking" quite amuzing. :-)
When Phoenix was talked about many people wrote that
* Phoenix is not real and that we are just lyers.
Now people complain about this and that feature.
Funnily these people have never used Phoenix, never seen it, and do not know how Phoenix really works.
Matt seems to be a big fan of Phoenix as he is so kind to explain people in forums
all over the place how Phoenix does this or that.
But mind that Matt has his knowledge only from interpreting my posts in the Apollo Forum.
This means his explanations often contain some misunderstandings and also outdated info which was changed long ago.
Its nice that Matt advertised for us.
Thank you Matt.
But please mind with all his explanations that Matt does not know the Phoenix sources,
and that he never had seen or used the Phoenix in real live.
So all information is hear-say from reading our forum...
If you want 100% reliable information then the best idea is to ask the people that know directly.
-
I actually don't doubt any of that and also think talk of ASIC or any other future step is premature. This is already likely to turn the amiga upgrade market upside down. When the board become available for all systems then we'll be able to see where to go next
-
Doom is running very smoothly there.It would be nice to see a demo video of the card booting up, running the OS and using a few programs to get an idea of the speed for general usage.
-
I have no idea what Gunnar and MattHey are arguing about due to I had a little disagreement with my Time Machine. I say I wired the 6581 SID chip in correctly but it says I wired it in backwards. Either way, the end result was that I accidentally got sent forwards in time 2 years instead of backwards. So I find myself materialized in the year 2015 and I have no idea what has been going on the last 2 years. :crazy:
If you want 100% reliable information then the best idea is to ask the people that know directly.
Ok. I would like to read the instruction manual for the new MiniApollo that you have crammed into Majsta's board. Where is it at?
Does it contain any new instructions that I can use to produce the World's Best 2D Strategy Board Game(tm) ?
Have you left away any instructions that you are saving for the rumored future A1200 Apollo card?
I don't care if certain compilers don't "support" the new instructions. The best compiler in the universe is sitting inside my head and it already supports a theoretically infinite number of new instructions.
-
n The best compiler in the universe is sitting inside my head and it already supports a theoretically infinite number of new instructions.
Bounty to open source that.
-
I would be very surprised if a compiler tries to take advantage of the extra vector/integer hybrid whatever registers
What is wrong with having vector registers added?
and 68k assembler fans are likely to turn up their nose also, Gunnar's new ISA is like trying to force a square peg through a round hole but he has decided that the square peg is better and that he will have it at all costs.
I am trying to understand what is the problem with the new ISA.
Could you give me some example instructions that are critical and should be added, but Gunnar banned them?
Did he add some good new instructions but chose stupid encodings for them?
Or ?
Remember I have no idea what has been going on with this. The last thing I remember, I was telling Majsta what a good job he was doing in trying to cook up an FPGA 680x0 CPU (It wasn't very fast, he had just started) and now all of a sudden it seems Gunnar has taken over and Doom is running at 22fps on A600.
-
Bounty to open source that.
Luckily a Black & Decker Power Drill + Crowbar are cheap. :lol:
-
Here is the A600's main CPU replaced with the Vampire 600 Accelerator:
(Apollo mini) Phoenix Core BETA v.1996 (https://www.dropbox.com/s/sn7btk4d7z8le79/apollo_mini_1996.mp4?dl=0)
Indeed, that's an A600 accelerator with it's own 32-bit address bus and 64MB local fast ram. I.e., not a stock A600 with a stock 68000 CPU. Anyway, enough of this.
-
Does it contain any new instructions that I can use to produce the World's Best 2D Strategy Board Game(tm) ?
Have you left away any instructions that you are saving for the rumored future A1200 Apollo card?
I don't care if certain compilers don't "support" the new instructions. T
The best place to ask this and get detailed information is
http://www.apollo-core.com/knowledge.php
If you have problems or urgent questions then the IRC channel is a place to get help.
In short answers:
Yes the core supports new instructions
Yes, the core supports more registers, or more flexible usage of old registers
Yes the core supports more flexiblel EA-modes
The core has a number of automatic performance enhabcing features
like e.g. streaming, prefetching, dual ported caches etc.
In addition to this the developer can use new features.
Like Branch Misprediction prevention
Like Parallel Memory Loads
Like Cache control
Even without using the new features the core is faster than any existing 68K core.
But using the new features will give you more.
-
@ Matthey
Could you tell us why you need an ASIC so badly? There is only one coldfire accelerator card for an Atari.
Seriously a $50 ras pi, must be a better choice for embedded systems. I don't feel a sudden need to control something from AmigaOS
The Raspberry Pi is $50 because it is an ASIC and not an fpga. A $50 Amiga Pi using an ASIC could:
1) be easier to program (embedded applications often ditch the OS so this is important)
2) use less memory and need less caches
3) have stronger memory performance and single core performance than the Rasberry Pi
An fpga CPU can't compete against a hard (ASIC) CPU in performance or price. The ColdFire has nothing to do with an ASIC other than that an ASIC needs to be sold in quantity to reduce the price and ColdFire support would open up the embedded market more. Most of the ColdFire enhancements are good for the 68k as well improving performance and code density which are especially valuable in embedded applications. They would also be good for emulation as the functionionality is available in many modern processors (sign and zero extension, endian conversion, etc.). ColdFire support is already available in most 68k/ColdFire shared compiler backends so it would be very easy to impliment. Atari 68k/ColdFire, the TG68 and WinUAE could possibly all adopt one unifying 68k standard which I don't think will happen with Gunnar's ISA.
I actually don't doubt any of that and also think talk of ASIC or any other future step is premature. This is already likely to turn the amiga upgrade market upside down. When the board become available for all systems then we'll be able to see where to go next
The FPGA needs to improve before an ASIC is viable but the decisions today affect how easy it would be to make an ASIC in the future. An ISA that is not well received and a non-standard outside of the Amiga community would make the possibility of an ASIC highly unlikely. Too much internal FPGA optimization like combining units could make the source code more difficult to adapt to an ASIC as well.
Ok. I would like to read the instruction manual for the new MiniApollo that you have crammed into Majsta's board. Where is it at?
Does it contain any new instructions that I can use to produce the World's Best 2D Strategy Board Game(tm) ?
Have you left away any instructions that you are saving for the rumored future A1200 Apollo card?
I would like to see the ISA documentation and encoding maps also. I would like knowledgeable people to take a look at it and have a discussion about it.
What is wrong with having vector registers added?
Nothing if they are in a vector unit. Let's ask ThoR what he thinks about overlaying 64 128 bit wide vector registers on the integer register file.
I am trying to understand what is the problem with the new ISA.
Could you give me some example instructions that are critical and should be added, but Gunnar banned them?
Gunnar didn't ban anything. He used ColdFire encoding space to add more integer registers which he unilaterally decided was more important than anything else.
Did he add some good new instructions but chose stupid encodings for them?
He has some instructions which I think would be acceptable and some that are questionable to add to a standardized ISA (like planar gfx instructions which may be ok in the core or as optional).
Remember I have no idea what has been going on with this. The last thing I remember, I was telling Majsta what a good job he was doing in trying to cook up an FPGA 680x0 CPU (It wasn't very fast, he had just started) and now all of a sudden it seems Gunnar has taken over and Doom is running at 22fps on A600.
Let's do a little time warp back to a time you remember. We go back past when Hyperion was bankrupt...back when the Natami was at it's peak generating over 300,000 hits in a single thread while Hyperion was selling a few hundred copies of AmigaOS 4 for the PPC...back when Gunnar was still part of Natami...Ok. Here we start in September of 2010. Gunnar was working on the Apollo/Natami core as a Natami Team member and brain storming for an new ISA. You were a Natami moderator then TCL and very active then. Gunnar suggested adding more registers then when some big Amiga names were on the Natami forum. The thread follows:
http://www.natami.net/knowledge.php?b=2¬e=26237
There were many suggestions about how to add more integer registers but the developers decision on more registers went something like this:
Gunnar von Boehn: yes, yes, yes
Ceti 331: yes, yes
Deep Sub Micron (Jens): no, maybe
Morgan Johansson: maybe
Claudio Wieland: maybe
Steve Thomas: maybe
Megol: maybe
ThoR: maybe, no
Phil "meynaf" G.: maybe, no
Cesare Di Mauro: no, no
Samuel D Crow: maybe, no
Marcel Verdaasdonk: maybe, no
Matt Hey: maybe, no
You were there TCL but you seemed to be moderating and didn't express an opinion that I could determine. By my count, I come up with 2 developers wanted it and 6 thought it was not a good idea. Note that Deep Sub Micron is one of the current Apollo developers and he could have been mildly in the no category but he still did try to come up with a workable solution to add more integer registers.
A 68k+ColdFire ISA was then developed with me documenting some of the better ideas and which was generally accepted as the Natami ISA. This is basically the 68kF ISA along with some ideas of my own and others since then. Gunnar left the Natami Team for reasons unknown (by some) and created the Apollo Team of which Meynaf and I were invited. Gunnar once again pushed adding registers but Meynaf and I didn't like the new idea preferring the 68k+ColdFire ideas better. Jens and Chris of the big 3 Apollo developers gave no input nor did anyone else have a major opinion. Gunner had free FPGA memory blocks to add more integer registers and determined that more registers were necessary for performance. Gunnar tried to get us to help encode and document this crazy ISA but we declined. It is true that I don't know the details of his ISA as it is less documented than the Natami ISA where there were encoding maps showing the 68k+ColdFire ISA. Rune Stensland even had enough info on the 68k+ColdFire ISA that he started adding support into the Asm Pro Assembler:
http://www.natami.net/knowledge.php?b=6¬e=33870
So I support much of what Gunnar has done with Phoenix but people need to realize that it is his pet/toy project. I'm not sure anyone with more Amiga clout than Meynaf or I could make a difference but I can say I tried. Maybe enough money could make a difference but I can't invest in his toy but only a community wide effort that is bigger than him. That is the end of story and maybe the end of the Amiga and 68k as well if some of the other important Amiga people don't change and begin cooperating very soon.
-
Adding more registers is fine with me. Is it possible to maintain coldfire compatibility as well?
How about you compile for compatible mode or Vampire core on the software side.
-
Adding more registers is fine with me. Is it possible to maintain coldfire compatibility as well?
Almost everyone would like more registers but what has to be give up to get them?
RISC processors give up powerful addressing modes and working directly in memory. They need several instructions for a simple load/store operation and bubbles are created when the code is not scheduled perfectly.
CISC requires more encoding space as the addressing mode as well as the register number is part of the instruction encoding. Some CISC processors like the x86/x86_64 use longer variable length encodings but this makes the code size bigger (x86->x86_64 programs are commonly 20%-40% larger and the caches have to be larger too). There is some free space in the 68k encoding map which includes the ColdFire MVS (Move with Sign extend) and MVZ (Move with Zero extend) but Gunnar's ISA would rather use this encoding for MOVEQ #,En so that his new registers don't enlarge the code. These are the most common ColdFire new instructions and without them it is a joke to call the processor CF compatible. The only other places big enough for the what Gunnar wants to do are A-line which is reserved on the 68k and would affect 68k compatibility for systems like Atari ST, Mac 68k, Sega Genesis, Neo-Geo, x68000, etc. where they are commonly used for function calls to the OS. The other place is F-line which is usually reserved for co-processors and an unknown amount of space would be needed in the future for a vector unit and possibly more. All the registers Gunnar wants to add eat up encoding space limiting other options. It would be possible to add a prefix encoding word (Megol pushed for this) which would give more consistent and orthogonal encodings but at the cost of larger instructions when using the new instructions and complexity in the core. Gunnar rejected this proposal. There are many trade-offs as you can see.
How about you compile for compatible mode or Vampire core on the software side.
The compatible mode would be the 68020 ISA from the late '80s. Amiga users are probably happy with a retro core like this but it would be a handicap when trying to sell for newer applications like embedded. With the ColdFire extensions and a few other minor ISA changes, we could be mostly ColdFire compatible at the instruction level and I believe we could be 5%-15% better code density (smaller code). Gunnar's major ISA changes are much riskier as far as acceptance and compatibility, especially for a FPGA processor with a tiny market, limited documentation and a lot of work for compilers.
-
Gunnar didn't ban anything. He used ColdFire encoding space to add more integer registers which he unilaterally decided was more important than anything else.
If he overwrote the ColdFire instructions with different instructions then he BANNED the ColdFire instructions from working.
If he had left the ColdFire instructions unimplemented then you or I or any random person could add those instructions in later.
But to enforce the BAN, he overwrote their bitpatterns with new incompatible instructions that serve a different purpose. Thus preventing their ColdFire use forever and ever.
Is there something about those instructions that just totally sucks?
If I would have had those coldfire instructions available to me in the 1980s, 1990s and 2000s then I would have used them and had faster code. But I have put no thought into them at all for around 10 years.
Does Gunnar have a logical reason to murder the coldfire instructions? Like they were stupid instructions? Or they were to slow? Or they bog down his ALU? Or they consume to many read/write ports? Or ?
-
Frankly here was quite some non-sense posted.
The A-line extension to NOT clash with ATARI or APPLE or any other old A-line usage.
Matt what you say is just technically not true. You should know this better.
Also you did say that the FPGA Vector implementation would prevent an ASIC version of the core.
As the way the Registerfile they way Apollo does it would not be good fro ASICS.
Again that is technically not true.
The latest and world fastest ASICS on the market use a merged Regfile just the same way as we do.
So this prooves that our solution is working perfectly in an ASIC and in fact is "state of the art".
Matt, we are very happy to discuss compiler optimizations ideas.
Technical ASIC/FPGA discussions should be done by people understanding them fully.
-
The Raspberry Pi is $50 because it is an ASIC and not an fpga.
The Raspberry Pi is cheap because it is based on an existing cheap SoC that could realistically be produced in quantities of millions of units for less esoteric purposes than as a replacement for a legacy CPU.
-
In 2009, gunnar von boehn promised NatAmi with a cpu many times faster than any ppc used in Amiga and with graphics better than PlayStation 3.
That's all for less than 100 euros.
Then every spring NatAmi team promised that this summer Natami will be produced.
Now it is 2015 and there is still nothing.
gunnar where is my NatAmi?
I want one!!!
Today gunnar von boehn only promises fpga cpu only as fast as 060.
After years of lies, broken promises, I do not believe gunnar.
-
In 2009, gunnar von boehn promised NatAmi with a cpu many times faster than any ppc used in Amiga and with graphics better than PlayStation 3.
That's all for less than 100 euros.
Then every spring NatAmi team promised that this summer Natami will be produced.
Now it is 2015 and there is still nothing.
gunnar where is my NatAmi?
I want one!!!
Today gunnar von boehn only promises fpga cpu only as fast as 060.
After years of lies, broken promises, I do not believe gunnar.
A price similar to the A1 was what I remember. Whatever happened to Natami is not relevant here. The Phoenix core had been demonstrated running faster than an 060 on an A600 via the Vampire board.
-
Will any of these accelerators be compatible the Amiga 1000?
Is there a r-pi that will connect to the floppy port of an Amiga?
Well, I did see some use r-pi as a fdd emulator.
-
Is there something about those [ColdFire] instructions that just totally sucks?
If I would have had those coldfire instructions available to me in the 1980s, 1990s and 2000s then I would have used them and had faster code. But I have put no thought into them at all for around 10 years.
Does Gunnar have a logical reason to murder the coldfire instructions? Like they were stupid instructions? Or they were to slow? Or they bog down his ALU? Or they consume to many read/write ports? Or ?
The only thing wrong with the ColdFire instructions is the ColdFire naming conventions which are not friendly, consistent or 68k like. The solution I came up with are 68k names with ColdFire aliases:
mvs.b -> sxtb.l (Sign eXtend Byte . Long)
mvs.w -> sxtw.l (Sign eXtend Word . Long)
mvz.b -> zxtb.l (Zero eXtend Byte . Long)
mvz.w -> zxtw.l (Zero eXtend Word . Long)
This 68k already has EXTB.L so SXT[B/W].L and ZXT[B/W].L are only a small variation. There is some other minor massaging here and therer. These instructions are quite valuable as they reduce the number of instructions, improve code density, allow for ColdFire compatibility, make x86 emulation easier, allow peephole optimizations in assemblers like vasm and are almost as easy to implement in compiler backends where they already exist for the ColdFire. Gunnar doesn't have anything against them but needed the encoding space and more to encode his non-orthogonal En registers (originally he called them D8-D15 which is even worse having a bunch of non-orthogal registers as data registers; A8 is bad enough).
The A-line extension to NOT clash with ATARI or APPLE or any other old A-line usage.
Matt what you say is just technically not true. You should know this better.
I didn't say you used A-line but rather that was one of your other options which you most certainly were considering (and from your reaction may have used). The 68k MacOS uses A-line for OS function calls as can clearly be seen in MacOS disassemblies:
196: 4268 0004 'Bh..' CLR 4(A0)
19A: 4228 0006 'B(..' CLR.B 6(A0)
19E: 4228 0007 'B(..' CLR.B 7(A0)
1A2: 43FA 036E 1000512 LEA data2,A1 ; len= 1
1A6: 45E8 0009 'E...' LEA 9(A0),A2
1AA: 4EBA 0392 100053E JSR proc2
1AE: 43FA 03A2 1000552 LEA data4,A1 ; 'Multi'
1B2: 4EBA 038A 100053E JSR proc2
1B6: 43FA 03AC 1000564 LEA data7,A1 ; len= 2
1BA: 4EBA 0382 100053E JSR proc2
1BE: 4A6E FFEC 200FFEC TST vab_2(A6)
1C2: 6756 100021A BEQ.S lab_13
1C4: 4FEF FFFE 'O...' LEA -2(A7),A7
1C8: 2F2E FFEE 200FFEE PUSH.L vab_3(A6)
1CC: 4EBA 2C88 1002E56 JSR proc29
1D0: 301F '0.' POP D0
1D2: 6646 100021A BNE.S lab_13
1D4: 4FEF FFCE 'O...' LEA -50(A7),A7
1D8: 204F ' O' MOVEA.L A7,A0
1DA: 317C FFF6 0018 '1|....' MOVE #$FFF6,ioCRefNum(A0)
1E0: 216E FFEE 001E 200FFEE MOVE.L vab_3(A6),ioSEBlkPtr(A0)
1E6: 317C 00FC 001A '1|....' MOVE #252,CSCode(A0)
1EC: A004 '..' _Control ; (A0|IOPB:ParamBlockRec):D0\OSErr
1EE: 4FEF 0032 'O..2' LEA 50(A7),A7
1F2: 206E FFEE 200FFEE MOVEA.L vab_3(A6),A0
1F6: A01F '..' _DisposPtr ; (A0/p:Ptr)
1F8: 486D FFFC -4 PEA glob1(A5)
1FC: A86E '.n' _InitGraf ; (globalPtr:Ptr)
1FE: A8FE '..' _InitFonts
200: A912 '..' _InitWindows
202: A9CC '..' _TeInit
204: 42A7 'B.' CLR.L -(A7)
206: A97B '.{' _InitDialogs ; (resumeProc:ProcPtr)
208: A850 '.P' _InitCursor
20A: 42B8 0A6C $A6C CLR.L DeskHook
20E: 487A 0302 1000512 PEA data2 ; len= 1
212: 4EBA 3198 10033AC JSR PUTREGISTERDLOG
216: 4EFA 0316 100052E JMP com_2
21A: 4227 'B'' lab_13 CLR.B -(A7)
21C: A99B '..' _SetResLoad ; (AutoLoad:BOOLEAN)
21E: 42A7 'B.' CLR.L -(A7)
220: 2F3C 4452 5652 '/ 226: 487A 2156 100237E PEA data35 ; len= 12
22A: A9A1 '..' _GetNamedResource ; (theType:ResType; name:Str255):Handle
22C: 1F3C 0001 '.<..' PUSH.B #1
230: A99B '..' _SetResLoad ; (AutoLoad:BOOLEAN)
The Atari and Sega Genenis may only use TRAP but the x68000 looks like it uses F-line for some OS calls which is not allowed in the 68k ISA documentation as A-line is. I don't know how the Neo-Geo calls functions. Of course ColdFire does not reserve A-line (it is not 68k) and placed MOV3Q in there which is one of the few 68k ColdFire incompatibilities.
Also you did say that the FPGA Vector implementation would prevent an ASIC version of the core.
As the way the Registerfile they way Apollo does it would not be good fro ASICS.
Again that is technically not true.
Technically it should be possible to make an ASIC with a combined vector and integer unit but nobody is going to make an ASIC out of such a screwed up CPU with such a screwed up ISA. It also may be more difficult to create an ASIC out of a ultra-optimized FPGA core all jumbled together.
Matt, we are very happy to discuss compiler optimizations ideas.
Technical ASIC/FPGA discussions should be done by people understanding them fully.
You are overbearing and dominate the "technical" decision making. I know enough about ISAs to know that you have chosen a radical ISA (see the Natami link above where you called more registers a "major ISA change") for a conservative maket which is all wrong. You had 25% support (including you so less excluding you) for more registers and your "major ISA changes". How are you going to get people to use something the majority doesn't support? Your ISA needs major work in compiler backends but how are are you going to gain support for an FPGA CPU with a few hundred users? Even if you were to overcome these large obstacles then how do you plan to compete against hard processors even with the extra registers? My ASIC plan is more feasible than your radical FPGA ISA. An ASIC isn't that expensive and raising money for what people want and like is a lot easier than trying to sell them what they don't want.
The Raspberry Pi is cheap because it is based on an existing cheap SoC that could realistically be produced in quantities of millions of units for less esoteric purposes than as a replacement for a legacy CPU.
An Amiga Cherry Pi (I like cherry better) would have to be a SoC ASIC to be close to as cheap as the Raspberry Pi. It would be difficult to compete with the Raspberry Pi in price and energy efficiency. I would rather target a DVD (optionally Blu-ray DVD) player box kind of like the old PS2 (which is way better than a cheap CD32) but with a removable DVD drive and more expandable (usb, ethernet, wifi, etc,). I think an ASIC enchanced 68k could play HD movies no problem. I would include an FPGA like a Cyclone V which could be used for emulation, acceleration of some tasks, and for embedded uses. It would eventually be able to emulate whatever gaming CD is placed in the drive up to a PS2. Keep everything open so people can use an internet browser (which still can't be done on the PS3). Using the AmigaOS or AROS 68k, 1GB of memory should be plenty. I would aim for a price of $100-200. We would probably need to sell 40k units. I wonder if there were that many people on the Natami forum in it's prime when it generated 300,000+ hits in one thread.
In 2009, gunnar von boehn promised NatAmi with a cpu many times faster than any ppc used in Amiga and with graphics better than PlayStation 3.
I recall a target of PS2 level performance and faster than a 68060. I believe Gunnar has delivered on the latter and had limited control of the former (I don't believe Gunnar can take all the blame for the hibernation of Natami).
That's all for less than 100 euros.
I didn't ever see anything close to this price although it's possible that someone was wishing for this price.
Then every spring NatAmi team promised that this summer Natami will be produced.
I don't recall any promises like this but there were a lot of expectations like this.
Now it is 2015 and there is still nothing.
gunnar where is my NatAmi?
I want my Natami too. Gunnar has the FPGA core that was needed to lower the cost of Natami mostly working and with good performance. Thomas Hirsch knows about it. Some people have different ideas about what team work and cooperation are though.
-
My ASIC plan is more feasible than your radical FPGA ISA. An ASIC isn't that expensive and raising money for what people want and like is a lot easier than trying to sell them what they don't want.
One of these "plans" is an already implemented and working solution that seems to give its users the fastest 68k alternative available. No need to consider feasibility at that stage.
An Amiga Cherry Pi (I like cherry better) would have to be a SoC ASIC to be close to as cheap as the Raspberry Pi. It would be difficult to compete with the Raspberry Pi in price and energy efficiency. I would rather target a DVD (optionally Blu-ray DVD) player box kind of like the old PS2 (which is way better than a cheap CD32) but with a removable DVD drive and more expandable (usb, ethernet, wifi, etc,). I think an ASIC enchanced 68k could play HD movies no problem. I would include an FPGA like a Cyclone V which could be used for emulation, acceleration of some tasks, and for embedded uses. It would eventually be able to emulate whatever gaming CD is placed in the drive up to a PS2. Keep everything open so people can use an internet browser (which still can't be done on the PS3). Using the AmigaOS or AROS 68k, 1GB of memory should be plenty. I would aim for a price of $100-200. We would probably need to sell 40k units. I wonder if there were that many people on the Natami forum in it's prime when it generated 300,000+ hits in one thread.
Cool. Wake me up from my cryo-sleep when you have a prototype ready! I'm sure people would have been interested in that DVD drive 15 years ago.
-
One of these "plans" is an already implemented and working solution that seems to give its users the fastest 68k alternative available. No need to consider feasibility at that stage.
I'm sure people would have been interested in a processor as fast as a 20 year old Pentium and with a 30 year old ISA 15 years ago :D.
Cool. Wake me up from my cryo-sleep when you have a prototype ready! I'm sure people would have been interested in that DVD drive 15 years ago.
It's important to keep the price down for the masses and provide more freedom with a replaceable drive. Some people would rather have a DVD-R than a Blu-ray read only drive for example. A DVD drive may be a good enough base standard but it depends on how cheap Blu-ray drives could be bought. Consoles, DVD/Blu-ray players and TV service boxes are too limiting and not open enough. It's really frustrating to have so much power sitting there and only being able to do what they will let you.
-
@MattHey
Here's an idea. If your processor design is so much better than Gunnar's then why don't you develop it and stop pestering the crap out of Gunnar!? Go off and develop your own!
-
i hope no bad blood develops here, just a discussion, because none can actually force the people doing work into something, but they might be convinced if the arguments are right.
meanwhile:
http://www.apollo-core.com/knowledge.php?b=1¬e=2679&z=qHDEuq
68020 support, i hope its full.
-
Technically it should be possible to make an ASIC .
An ASIC always sounds nice.
But I think that using FPGA has lots of advantages too.
In an FPGA you can test and evolve the design over and over again.
The Vampire 600 FPGA is not big, and when we started the port
of Apollo to it, I was not sure that we could fit much of Apollo in it.
The FPGA allowed to tweak, tune, and optimise the design.
and now we have 68020 software support and still not to bad performance and all this in this small FPGA.
This shows the big advantage that FPGA give you for development.
You can tune and tweak and develop 100 evolutions of a design.
Producing 100 ASIC evolutions would have cost a fortune....
Low end FPGA are not costly.
So the ASIC has not even price advantage to very low end FPGAs.
The only real advantage on an ASIC would be speed.
Sure with an ASIC we could dream of reaching a gigaherz ...
But we are not there yet - we need a lot more time to develop our ideas.
To test the SAGA chipset etc.
And for this FPGAs are really great.
-
@gunnar
couldnt agree more.
-
Yup, FPGAs are ideal for what we need at the moment. Quite possibly the savior of Amiga tech. No-one would have enough money to bake multiple ASIC revisions for testing purposes.
-
I agree, FPGA is cheap enough and fast enough for m68k AmigaOS. Matthey, I understand your concerns, and I'm sure your points will materialize themselves when/if no compilers supports the changes/improvements that Gunnar has done. In the meantime, I dont think anyone/anything prevents someone else, for example you, from doing a more "conservative" m68k core for the Vampire boards.
But yeah, a m68k cherry pi would be awesome, I would guaranteed buy a few, especially if the m68k has MMU and can run Linux, I want real hardware for my Linux/m68k again ;)
My suggestion is to ignore what Gunnar is doing and join forces with other more likeminded people and "do it right", the best solution will win, right?
-
I'm sure people would have been interested in a processor as fast as a 20 year old Pentium and with a 30 year old ISA 15 years ago :D.
It's important to keep the price down for the masses and provide more freedom with a replaceable drive. Some people would rather have a DVD-R than a Blu-ray read only drive for example. A DVD drive may be a good enough base standard but it depends on how cheap Blu-ray drives could be bought. Consoles, DVD/Blu-ray players and TV service boxes are too limiting and not open enough. It's really frustrating to have so much power sitting there and only being able to do what they will let you.
I am sure that you are honest with what you are writing and really mean it but for now Gunnar offers the best 68k solution ever available and a payable also. That is what we need, a major hardware upgrade including 68k (at least 68020 compatible) and better graphics and sounds. I do not know whom you know or not but I do not believe at people investing millions of dollars in the market, not before products are there and the need is obvious. When you can show a working system and proof your concept by sales then you can go to a investor, not the other way round. Investors are cold calculators, they look how big is risk, what have I to invest and what do I earn and they expect a business plan. So first step is a working FPGA based system that can already be used with software being adapted to. I think we should gunnar simply let do his job. I see (from videos) more and more software running at a very high speed (and there is no improved chipset/RTG yet) that counts for me (and most others) and not abstract discussions about ISA details.
-
I take it for granted that people here are aware of FPGA Arcade and MiST? There seem to be many m68k softcores around, I suspect they are based on TG68.
-
I recall a target of PS2 level performance and faster than a 68060.
I recall a target of PS3 level performance, gunnar von boehn later changed his promises to PS2 level performance. gunnar always promised that the cpu will be faster than g4.
gunnar where is my Natami ?
-
I recall a target of PS3 level performance, gunnar von boehn later changed his promises to PS2 level performance. gunnar always promised that the cpu will be faster than g4.
gunnar where is my Natami ?
you say that as though it is your god given right to have it, I can give you a link so you can find some literature so you can start your own research...
https://www.google.com (https://www.google.com)
I think it is awesome that there is still even development for the Amiga so support them
-
@kipper2k
he is probably already on a list of individuals not to be served, as well as on ignore list where possible.
-
you say that as though it is your god given right to have it, I can give you a link so you can find some literature so you can start your own research...
https://www.google.com
I think it is awesome that there is still even development for the Amiga so support them
LOL. Well played, @kipper2k. And might I say, it's lovely having you on our forums here, now. That's some great hardware you produce, don't let any of these naysayers drag you down! :hammer:
-
I agree, FPGA is cheap enough and fast enough for m68k AmigaOS. Matthey, I understand your concerns, and I'm sure your points will materialize themselves when/if no compilers supports the changes/improvements that Gunnar has done. In the meantime, I dont think anyone/anything prevents someone else, for example you, from doing a more "conservative" m68k core for the Vampire boards.
FPGAs are wonderful tools for core development but the 68k will never be more than retro (and a slim chance for embedded) as FPGA only. A more compatible core and ISA is needed for both retro and embedded instead of an unused "performance" ISA which Gunnar is targetting. The following Atari forum link with one of the Mist creators talks about the Phoenix core on Mist:
http://www.atari-forum.com/viewtopic.php?f=101&t=27442&sid=20370baaedca3a502b06a214d70aa186
Compatibility is the first concern, then license, and performance is nice but less important. I bet the concerns are the same for other 68k FPGA hardware creators. I expect embedded markets to be the same way. Existing embedded 68k and ColdFire customers may want something faster but they need compatibility with their current code base. Phoenix isn't going to win over ARM customers overnight but it could win existing 68k and ColdFire customers if it was compatible enough and liked enough (radical 68k changes won't fly with these 68k fans any more than the retro guys). We are also missing an oppurtunity to have one united 68k standard which could be used in Phoenix, TG68, Suska, UAE, and with so many people using one standard, more likely an eventual ASIC. Instead, we could end up with another incompatible Amiga split like the current ones which are killing Amiga.
But yeah, a m68k cherry pi would be awesome, I would guaranteed buy a few, especially if the m68k has MMU and can run Linux, I want real hardware for my Linux/m68k again ;)
While the 68k integer and FPU ISA need a little refreshing and modernization, the 68k MMU design needs major changes. It may not be practical to keep it compatible. It would be good to investigate ways to ease adding at least partial memory protection and/or memory isolation and extended memory into the AmigaOS while also allowing for possible future SMP (AmigaOS 3 using a custom CPU has a better chance to maintain compatibility than AmigaOS 4 using an off the shelf CPU). ThoR needs to be involved and design us a new MMU standard ;).
My suggestion is to ignore what Gunnar is doing and join forces with other more likeminded people and "do it right", the best solution will win, right?
Like with AmigaOS 4, MOS, AROS, AmigaOS 3, etc.? Is the best Amiga winning or is all of Amiga losing?
I am sure that you are honest with what you are writing and really mean it but for now Gunnar offers the best 68k solution ever available and a payable also. That is what we need, a major hardware upgrade including 68k (at least 68020 compatible) and better graphics and sounds. I do not know whom you know or not but I do not believe at people investing millions of dollars in the market, not before products are there and the need is obvious. When you can show a working system and proof your concept by sales then you can go to a investor, not the other way round. Investors are cold calculators, they look how big is risk, what have I to invest and what do I earn and they expect a business plan. So first step is a working FPGA based system that can already be used with software being adapted to. I think we should gunnar simply let do his job. I see (from videos) more and more software running at a very high speed (and there is no improved chipset/RTG yet) that counts for me (and most others) and not abstract discussions about ISA details.
I agree that new affordable 68k hardware is what the Amiga needs but we need to plan and work together to keep the 68k Amiga pipeline full, to put it in processor terms. It is important to have a product to show but it is also important to have a good plan to show investors. I am an investor and I know other investors. You might be surprised by what I could make happen but I'm sure not going to pull my money out of safer investments to invest in something I don't believe in and in people I can't trust. Neither will I try to convince other investors to do the same or try to find other partners to invest with. I see potential here but I do not see anything investable yet.
I recall a target of PS3 level performance, gunnar von boehn later changed his promises to PS2 level performance. gunnar always promised that the cpu will be faster than g4.
Any mention of PS3 performance must have been before I was involved with Natami which wasn't particularly early. The PS3 has a lot of potential performance but it it difficult to take advantage of. An enhanced 68k Amiga SoC ASIC with good 3D implementation added might not have as much theoretical performance but could be much easier to program perhaps making it seem surprising close to the performance of a PS3. I think a Cherry Pi could be made which could outperform the new Raspberry Pi 2 at a moderatly higher cost, with everyone working together and with proper funding (oddly never tried with the Natami despite tremendous interest).
I believe the current Phoenix core outperforms a PPC G4 clock for clock in integer performance and in memory performance. Enable the 2nd (and possibly 3rd) integer pipe, clock it up, up the caches, add branch prediction and add an FPU and it should be able to walk all over an equally clocked G4.
-
Even if a PS3 level performance was promised (I recall vaguely PS2 performance promises) it wouldn't have been with the Vampire 600 SoC, it would have been with the failed Natami board, which used a significantly larger FPGA and was to sell for hundreds of dollars/euros/pounds.
-
I am an investor and I know other investors.
I wouldn't invest in anything that uses CDs/DVDs/BlueRays... these are sone ninetish... I don't know anybody that uses that obsolete media... terabyte sized HDs&network wins. Please no bulky and limited sized CDs/DVDs/BlueRays... I prefer to use a small Raspberry Pi as media center. If I was interested in CDs/DVDs/BlueRays I would connect it through USB. I don't plan to buy a blueray reader/burner ever anyway. I prefer hard disks. Even better, I prefer to quickly download stuff from everywhere I am rather than searching my entire collection (oh it was scratched by a friend, oh my friend didn't gave it back to me, oh where did I stored it... in my parent's house or in my gf's house).
Please, do not make a CD/DVD/BlueRay player. No one uses that in this millenium. Do you think that Raspberry would sell better with a DVD attached? Even if it costed the same? I don't want a DVD burner even if you gave it to me free and you paid shipping.
Some kind of raspberry pi like miggy could be more interesting? Give it USB and and a PCI-E bus male connector. You want expansion and various cards? you connect the board to a PCI-Express busboard (or pc) or feed it with power from it. Give it a GPIO pins, some USB ports and HDMI/audio out. Include a mini-SDXC connector to make it boot. You can buy an ethernet-usb card for around 6Euros. WiFi usb cards are cheap too (12€?). If you want stuff like SATA, Gigabit Ethernet, Advanced soundcards you could access PCIe bus. You could even draw the final gfx on the host's gfx card memory
-
The Raspberry Pi 2 certainly has the guts if not the memory to be a useful emulator.
http://au.element14.com/raspberry-pi/raspberrypi-2-modb-1gb/sbc-raspberry-pi-2-model-b-1gb/dp/2461030?CMP=KNC-YAH-COM-RPI
-
I wouldn't invest in anything that uses CDs/DVDs/BlueRays... these are sone ninetish... I don't know anybody that uses that obsolete media... terabyte sized HDs&network wins. Please no bulky and limited sized CDs/DVDs/BlueRays... I prefer to use a small Raspberry Pi as media center. If I was interested in CDs/DVDs/BlueRays I would connect it through USB. I don't plan to buy a blueray reader/burner ever anyway. I prefer hard disks. Even better, I prefer to quickly download stuff from everywhere I am rather than searching my entire collection (oh it was scratched by a friend, oh my friend didn't gave it back to me, oh where did I stored it... in my parent's house or in my gf's house).
It would make sense to sell units without a DVD/Blu-ray drive and even as a bare board to sell the most boards which lowers costs. I encourage downloadable software and software stores also. However, a DVD drive is cheap and probably should be part of a base Amiga standard. The media is cheaper than USB memory sticks where physical data is more convenient to distribute and/or where people prefer it. It makes a lot of sense for a retro emulation box where old game CDs could be inserted and played including CD32 games (see new CD32 games on EAB). It makes sense to be able to play DVD/Blu-ray movies which some people have. Some people would rather have a smaller but faster solid state hard drive rather than put several hundred GBs of games on their HD. How do you backup several hundred GBs of data on your HD? Eventually, maybe we would have an Amiga cloud for backup but everyone knows big brother has back doors to data stored on servers which some Amiga people won't like and it might not be possible to offer this service for free. A writable DVD would allow another option for backup of hard drives too large for memory sticks and they could burn their own old game CDs. I like freedom but it also means respecting the freedom of others including other users and developers. The situation can usually be better for everyone if we choose and use standards.
Please, do not make a CD/DVD/BlueRay player. No one uses that in this millenium. Do you think that Raspberry would sell better with a DVD attached? Even if it costed the same? I don't want a DVD burner even if you gave it to me free and you paid shipping.
That is a tough question. If Raspberry Pi came equipped to play HD movies and had a DVD/Blu-Ray drive, it would sell many systems as a movie player. Raspberry Pi software could be sold in stores making it more mainstream and competitive with PCs. Raspberry Pi itself could be sold in stores if it came in a box helping to sell more units. It would probably cost 2x-5x more which would turn some people off though. Overall, it would be different like the difference between Raspberry Pi and Cherry Pi.
Some kind of raspberry pi like miggy could be more interesting? Give it USB and and a PCI-E bus male connector. You want expansion and various cards? you connect the board to a PCI-Express busboard (or pc) or feed it with power from it. Give it a GPIO pins, some USB ports and HDMI/audio out. Include a mini-SDXC connector to make it boot. You can buy an ethernet-usb card for around 6Euros. WiFi usb cards are cheap too (12€?). If you want stuff like SATA, Gigabit Ethernet, Advanced soundcards you could access PCIe bus. You could even draw the final gfx on the host's gfx card memory
I would like to see more and more modern hardware expansion also but this has more potentential to increase costs and board sizes than adding a DVD/Blu-ray drive. We would have to do some cost/benefit analysis and maybe potential user opinion polls.
The Raspberry Pi 2 certainly has the guts if not the memory to be a useful emulator.
http://au.element14.com/raspberry-pi/raspberrypi-2-modb-1gb/sbc-raspberry-pi-2-model-b-1gb/dp/2461030?CMP=KNC-YAH-COM-RPI
Yea, the Raspberry Pi 2 is a nice upgrade which makes it usable as a regular computer. Each core of the processor is stronger than before but still relatively weak in order Thumb2 ARM. The extra cores will help a lot for some tasks where SMP is possible like web browsing while providing good power efficiency. Emulation and many games are single threaded needing strong integer performance which it doesn't have compared to even a low end Atom. The Neon vector unit and GPU may give a big boost in some cases but these aren't so simple to optimize for. Don't be surprised when your iPhone outperforms it. However, the price is great for the performance, it's efficient and it's open. I may pick one up myself.
-
@ above
Is it possible to build something like an Amiga on a chip? You could start with something small that would sell in great numbers, then you could move to an Amiga games console.
-
@ above
Is it possible to build something like an Amiga on a chip? You could start with something small that would sell in great numbers, then you could move to an Amiga games console.
Certainly. It's already mostly done with an FPGA 68k CPU and FPGA Amiga chipset together in a big fpga. There are even multiple resources to choose from (CPU: Phoenix, TG68, Suska; Chipset: MiniMig, SAGA). Some things should be added, improved and modernized though. 3D would be very nice and would have to be developed or bought. After everything is debugged, an ASIC can be burned.
-
sell in great numbers
You mean sell in "great numbers", right? :lol:
-
Matthey, you are essencially saying that the future of for a 68k FPGA core relies on Gunnar, I would say that this is to give him _way_ too much credit. I say this again - ignore Gunnar. You have repeatedly said the Apollo/Phoenix is his hobby project, so take your ideas to people who do give a damn, be it atari folks, minimig developers, UAE developers, whoever. Nobody wants a platform that relies on _one_ person.
-
kipper2k crap that you made is worth nothing crap.
if you work with Gunnar, it's clear why gunnar still not sell NatAmi.
gunnar where is my natami?
-
Matthey, you are essencially saying that the future of for a 68k FPGA core relies on Gunnar, I would say that this is to give him _way_ too much credit. I say this again - ignore Gunnar. You have repeatedly said the Apollo/Phoenix is his hobby project, so take your ideas to people who do give a damn, be it atari folks, minimig developers, UAE developers, whoever. Nobody wants a platform that relies on _one_ person.
Where is your FPGA Amiga?
-
kipper2k crap that you made is worth nothing crap.
if you work with Gunnar, it's clear why gunnar still not sell NatAmi.
gunnar where is my natami?
please search for another playground. It gets boring
BTW what are you contributing?
-
ppcamiga1 crap that you made is worth nothing crap.
if you work with ppcamiga1, it's clear why ppcamiga1 still not sell anything.
ppcamiga1 where is my brain?
Fixed that for you...
-
I believe the current Phoenix core outperforms a PPC G4 clock for clock in integer performance and in memory performance. Enable the 2nd (and possibly 3rd) integer pipe, clock it up, up the caches, add branch prediction and add an FPU and it should be able to walk all over an equally clocked G4.
gunnar von boehn promised cpu faster than g4 in 2009.
After six years gunnar von boehn has a 200 MHz CPU as fast as 060 50 MHz.
It is really hard to believe that gunnar ever finish his cpu, and it will be as fast as gunnar promised.
gunnar where is my natami?
-
Fixed that for you...
cunnpole crap that you made is worth nothing crap.
if you work with cunnpole, it's clear why cunnpole still not sell anything.
cunnpole where is your brain?
-
I'm sure people would have been interested in a processor as fast as a 20 year old Pentium and with a 30 year old ISA
For now gunnar cpu is as fast as 060 50 MHz, which means it is slower than 20 year old Pentium.
-
Matthey, you are essencially saying that the future of for a 68k FPGA core relies on Gunnar, I would say that this is to give him _way_ too much credit. I say this again - ignore Gunnar.
I think it's good advice.
You can wait forever for a fast cpu from gunnar.
If future of 68k FPGA depends on gunnar, then 68k FPGA will have no future.
-
For now gunnar cpu is as fast as 060 50 MHz, which means it is slower than 20 year old Pentium.
Well, I think the majority that are following Gunnars progress is hoping to speed up their Classic hardware. While my A1200 with Blizzard 030/50 and 18 megs of ram are doing ok, I wouldnt mind a 060 with 64/128/256 megs of ram+RTG.
I would never expect it to outpreform anything on the massconsumtion market today, but it would give my A1200 the horsepower to upgrade/tweak AOS 3.x and use more demanding programs that at the moment puts it at a crawl.
Purpose?
For fun (and some usefulness im sure).
-
I think it's good advice.
You can wait forever for a fast cpu from gunnar.
If future of 68k FPGA depends on gunnar, then 68k FPGA will have no future.
Were it not you who longly explained why 68k is a bad choice and PPC the way to go and how superior PPC is. If this is true what are you fearing? You seem to become nervous it seems. No reason yet but this might change :).
I do not understand why your crusade now against Gunnar. If he not delivers what do you loose? What have you invested in the project? I cannot remember you to be there so what is your problem?
-
Well, I think the majority that are following Gunnars progress is hoping to speed up their Classic hardware. While my A1200 with Blizzard 030/50 and 18 megs of ram are doing ok, I wouldnt mind a 060 with 64/128/256 megs of ram+RTG.
I would never expect it to outpreform anything on the massconsumtion market today, but it would give my A1200 the horsepower to upgrade/tweak AOS 3.x and use more demanding programs that at the moment puts it at a crawl.
Purpose?
For fun (and some usefulness im sure).
That is what is promised. A nice little toy and for the next generation it might even come in a range where you can use it for average tasks. Not more not less.
-
Technically it should be possible to make an ASIC
I really wonder if it makes sense to make an ASIC.
In the V600 FPGA we see an average performance of ~ 200 MHz 68020
Our expectations for the next card is a performance about 3 times higher
e.g ~ 600 MHz 68020
And the card will still be very affortable compared to 68060 cards.
Not if we would spend money on a fast FPGA - like people spend money on 68060 cards.
Then we could again double the value and reach a performance on a ballpark of over a Gigaherz 68020.
Do we really need an ASIC?
-
Most of us here have no interest in spending the heaps of dollars to get an ASIC developed.
There is such a lack of modern software, you would not get new customers.
Maybe at a later date when there are more potential buyers it might be nice to do.
-
If the amgia on a chip was turned into an asic, could ram be put on board too?
It would be cool to see an asic get made. Do asic's run faster and use less power?
-
Where is your FPGA Amiga?
Stored in a container back home while I'm backpacking central and south America. I expect to have a couple more of them when I get back home.
-
I really wonder if it makes sense to make an ASIC.
In the V600 FPGA we see an average performance of ~ 200 MHz 68020
Our expectations for the next card is a performance about 3 times higher
e.g ~ 600 MHz 68020
And the card will still be very affortable compared to 68060 cards.
Now if we would spend money on a fast FPGA - like people spend money on 68060 cards.
Then we could again double the value and reach a performance on a ballpark of over a Gigaherz 68020.
The Phoenix core offers excellent performance/price for Amiga hardware. This can help reduce the 68k market deterioration and probably even bring back some users who recently left or have NG Amigas. The performance/price of the Phoenix CPU compared to any hard CPU is only going to attract geeks who realize how awesome a customizable CPU is. An FPGA is too expensive to make it cheap enough for mass produced hardware like the Raspberry Pi and never high enough performance for the affordable high end CPU market and thus remains niche. I think there is still a smaller retro and embedded market as an FPGA if the CPU is debugged to maturity, development and OS software is improved and standards are adopted with good documentation. It would probably help proliferation to either create a business or open source the core. The current Amiga and Hyperion situation is bad for anyone wanting to do Amiga related business though. It might be worthwhile to at least look into obtaining ownership rights to the AmigaOS if the situation became investable (AROS is of course the other option). Some level of investment would probably be required to move the Amiga out of it's niche into something interesting and marketable to the rest of the world. I believe an ASIC would be a necessary part of that equation for a 68k Amiga but it would require the sacrifice and cooperation of the Amiga community which has never been seen.
Do we really need an ASIC?
No, but did necessity keep Apple from becoming the most valuable business in the world? An ASIC is not necessary to have fun with Phoenix but if you are going to the trouble of making a fast FPGA CPU then you have already done most of the work for a faster ASIC CPU. It makes me wonder, if you can do that with an FPGA, what could an ASIC do? It's like sending an unmanned rocket to the moon and then deciding we are done because we proved our point and that is good enough.
Most of us here have no interest in spending the heaps of dollars to get an ASIC developed.
There is such a lack of modern software, you would not get new customers.
Maybe at a later date when there are more potential buyers it might be nice to do.
It's the chicken and the egg syndrome. There is not enough new Amiga software because there is not enough affordable Amiga hardware and there is not enough affordable Amiga hardware because there is not enough new Amiga software. Without interfering in this tailspin, the Amiga will crash and burn at some point. IMO, the hardware situation is better to attack because it expands the number of users who can buy and develop new software. Trevor@A-Eon is working on the software approach by buying old software and using a web store which is a good idea to maximize sales to existing Amiga owners and should help sell some NG Amigas by increasing demand but I wonder if the gains are bottlenecked by the high cost of the NG Amiga hardware. Also, we may be in danger of running out of good developers as they are assigned to update his software products ;).
If the amiga on a chip was turned into an asic, could ram be put on board too?
Yes, there is generally high speed memory on a hard CPU or ASIC CPU but it is commonly configured as caches because that is where it provides the most advantage. There is sometimes CPU addressable SRAM especially for embedded applications. This reduces the chip count of boards but SRAM is generally not practical in large sizes (>8MB?). Modern processors like the i7 have *huge* caches which would be more than enough to run the 68k AmigaOS if it was addressable by the CPU instead of caches. Would you rather have less memory that is faster or more memory that is slower? The latter is probably more useful with modern software as most of the data could be in the 68k caches (The 68k is a cache miser so 32kB ICache and 32kB DCache should be a lot).
It would be cool to see an asic get made. Do asic's run faster and use less power?
ASICs are generally considerably faster than an FPGA but an FPGA can hold it's own in parallel tasks. ASIC and hard processors usually use less power but may require some work to improve power efficiency. FPGAs are low power already, especially for retro use. For embedded markets, the lower the power use and/or the better the performance for the power use, the better.
-
The Phoenix core offers excellent performance/price for Amiga hardware.
Thanks
An FPGA is too expensive to make it cheap enough for mass produced hardware like the Raspberry Pi
What would be the pricepoint in your opinion for the FPGA/ASIC?
Lets say we wanted to build a new retro AMIGA with 600 MHz 68020 performance, fast FPU
256 MB fast memory, SAGA (truecolor) chipset ...
What in your opinion is the price break for the FPGA of such a system?
At which price you would say the FPGA is ideal for this?
-
Thanks
What would be the pricepoint in your opinion for the FPGA/ASIC?
Lets say we wanted to build a new retro AMIGA with 600 MHz 68020 performance, fast FPU
256 MB fast memory, SAGA (truecolor) chipset ...
What in your opinion is the price break for the FPGA of such a system?
At which price you would say the FPGA is ideal for this?
I will just chip in, with my coder iliterate opinion;
If you broke down your expenses and told the community that to even break even on the components the price is; xxx dollars/euros.
Ontop of that we have spent x 100's or 1000's of hours actually making that, so we would like to see some return for our efforts and future development.
Putting a 10, 20, 30, 40% etc profit margin ontop of bare cost is something the MAJORITY of people will understand, cause its hard to quantify the hours spent, espesically on hobby projects that spans over years. There will always be people that want stuff for component break even pricepoint, but those can just be ignored ;)
-
What would be the pricepoint in your opinion for the FPGA/ASIC?
Lets say we wanted to build a new retro AMIGA with 600 MHz 68020 performance, fast FPU
256 MB fast memory, SAGA (truecolor) chipset ...
What in your opinion is the price break for the FPGA of such a system?
At which price you would say the FPGA is ideal for this?
I think I know where you are going. From a business standpoint, it would be much less risky to make a limited supply of FPGA boards (and accelerators) for as cheap as is reasonable and sell for as much as possible. Looking at current FPGA stand alone boards, we see a price of $200-$300 U.S. for good quality boards with low to mid range Amiga specs. That is in competition with a $35 U.S base price for the Rasberry Pi using emulation. With 1% of the Pi sales, the FPGA boards would have sold 50,000 units. Unfortunatly, the current FPGA board prices are a little high, the CPU performance is weak, the FPGA sizes could be larger, memory sizes are inadequate for general computing and there is little in the way of a standard platform. Some retro gamers would appreciate the more accurate FPGA emulation and pay up but most are choosing the Pi. It would be difficult to make a competive FPGA board with higher specs but substantially cheaper than current FPGA boards. An ASIC could make it possible to reach the $100-$150 range with competive specs to the Pi but with a little more expansion and a few more niceties to try to grab a few percentage of the Pi market (maybe a case would allow to sell in stores too). I bet at least 10% of Pi sales have gone to people that would prefer to have an Amiga computer or 68k CPU but only Raspberry Pi was offered instead of Cherry Pi. Let's say only 3% would have payed up for the Amiga or 68k which would be 150,000 potential Amiga users. That is easily enough to make an ASIC worthwhile. The risk is higher but if the goal is to increase the Amiga user base instead of making the most short term profits, there is potential. Investing in such a plan may be more appealing to those who are already invested in the Amiga or it could be throughing good money after bad. Some of the risk could also be reduced by finding good partners to help lower costs. I was looking at embedded where the fastest 68k and ColdFire CPU on the market could sell on it's own if it was compatible enough. I believe the Pi received very good pricing and arrangments from supplies as well. The Raspberry Pi Foundation promotes computer learning and CISC Pi is very different from RISC Pi so maybe they could be approached to gain some of the same resources and support (David Braben of Elite fame is one of the founders). There is a lot more outside of the Amiga niche that could be explored if we were organized and cooperating.
Edit: There have been more than 5 million Pi sales now so I updated some numbers.
-
Thanks
What would be the pricepoint in your opinion for the FPGA/ASIC?
Lets say we wanted to build a new retro AMIGA with 600 MHz 68020 performance, fast FPU
256 MB fast memory, SAGA (truecolor) chipset ...
What in your opinion is the price break for the FPGA of such a system?
At which price you would say the FPGA is ideal for this?
I hate to say it but it would have to be around $200 to sell big (relatively speaking). You can already buy an awesome retro computer for $50.
You'd still sell some at $500 but not that many I think
-
Looking at current FPGA stand alone boards, we see a price of $200-$300 U.S. for good quality boards with low to mid range Amiga specs. .
you compare apples and oranges.
The current FPGA boards for AMIGA have quite high prices for what they offer.
That these board have so high prices DOES NOT mean that an FPGA is more expensive than an ASIC.
An FPGA board with 256 MB fastmem, and 68020 CPU with 600 Mhz performance and SAGA could today be sold for less than $100. If a few thousand would be produced.
-
I hate to say it but it would have to be around $200 to sell big (relatively speaking). You can already buy an awesome retro computer for $50.
You'd still sell some at $500 but not that many I think
I could give you this for $200 today easily.
-
Looking at the prices for second hand Amigas there must be a market for new machines at $200-300. You are never going to compete with the raspberry pi or the dozens of other arm single board computers on cost. What you could do is try and cut a deal to licence the Amiga name. A small desktop system baring the official Amiga brand with a real amiga 68K operating system and chipset but much more powerful than any previous 68k Amiga would be a winning combination in my opinion.
-
@biggun
There is clearly a market for both higher cost and lower cost. I'd say there is even market for super high end. Heck look at the second hand market, whenever a Blizzard 1260 comes up it sells very quickly and those go for 500€ or more.
-
Right now any performance improvement is welcome to me.
Good work to all that are working on this project.
I encourage you to continue to work on it.
-
I'd guess that there is a "high-end" market for something like a 1-2G ram machine with 32bit 1920x1200 (or higher) for approx 1000 $/EUR/UKP. Doesn't have to include cabinet/ps.
If you want to add a little extra value / up the price, then I would love to have it delivered in an A1000 cabinet. (I am seriously beginning to think about getting an A1000 purely for aesthetic reasons - not to use it.)
-
Well, high end production entails alot of financial risk for the producers.
Which Id say NovaCoders 200 dollar quote seems more sensible... or?
The original quote about 64 megs memory was cause they wanted to keep it simple(ish) and cheap with existing hardware.
-
An FPGA board with 256 MB fastmem, and 68020 CPU with 600 Mhz performance and SAGA could today be sold for less than $100. If a few thousand would be produced.
(http://i0.kym-cdn.com/photos/images/original/000/181/813/1726009-shut_up_and_take_my_money_super.jpg)
-
Well, high end production entails alot of financial risk for the producers.
why not make a crowfunding campaign in kickstarter?
-
why not make a crowfunding campaign in kickstarter?
I was thinking the same, but that moves the project from "hobby" project they do at their own time, to "serious bissniss" where you have "customers" that will demand this/that and when nonstop ;)
But Ill let biggun comment.
-
i trust gunnar and the project members will consider options in due time. so far i very much agree with the roadmap. its too early to speak of asic. the project must gain some testing, popularity and must progress further. then it may become computable what audience it may achieve and what it may offer and then a campaign would make sense. i admire the realism not to do it now.
-
Do we really need an ASIC?
Of course not, ASICs, even on an older process (90/65nm) are horrendously expensive for the potential market.
FPGAs are more than enough - a ~600Mhz 68020 equivalent is more than enough for any 68k Amiga software that's ever been written.
PowerPC? Well, some FPGAs include PowerPC cores that could potentially be wired in.
-
I bet at least 10% of Pi sales have gone to people that would prefer to have an Amiga computer or 68k CPU but only Raspberry Pi was offered instead of Cherry Pi. Let's say only 3% would have payed up for the Amiga or 68k which would be 150,000 potential Amiga users.
I would say this is a huge over estimate, huge huge HUGE over estimate!!!
It would surprise me a lot if a 68k Cherry pi would sell much at all, probably less than 5000. At least without a full fledge capable CPU with MMU, so that it easily can boot a relevant operating system.
I think you have misunderstood why people buy the raspberry pi, it's not just because it is cheap, it is because it is cheap and fully supported bu Linux. Extremely few are interested in a lamed down EC 68k that only can run AmigaOS and maybe uCLinux if you are lucky.
-
I could give you this for $200 today easily.
Sold, you make it I'll buy it.
-
If it can replace my CS3 060 on my A4Kt with all that it has, I'm sold. Bring it on!
-
you compare apples and oranges.
The current FPGA boards for AMIGA have quite high prices for what they offer.
That these board have so high prices DOES NOT mean that an FPGA is more expensive than an ASIC.
An FPGA board with 256 MB fastmem, and 68020 CPU with 600 Mhz performance and SAGA could today be sold for less than $100. If a few thousand would be produced.
How much could the Natami MX board have sold for if a few thousand would have been produced?
How much would the cost increase to have 1GB of memory?
Your specs above and estimated per unit board price may win the apples vs oranges battle using an FPGA and economies of scale but you may only win a few hundred new Amiga users than the existing FPGA boards. That's not bad and it is cheap enough to give as Christmas presents at that point but does it win the bigger battle. We could win thousands and maybe tens of thousands of Amiga users with a product that could grab a potion of the Raspberry Pi pie. There are people who like Cherry Pie but if all they get is a little piece when they could have a big piece of Raspberry Pi for less cost, which are they going to choose? Your specs above are great for the Amiga market but not very competitive against the Raspberry Pi. I'm not saying that your board with an FPGA would be wrong for a first round of production but if gaining lots of Amiga users is the goal then planning, cooperating and setting standards toward a possible ASIC design is a worthwhile strategy IMO.
why not make a crowfunding campaign in kickstarter?
We all wondered why this didn't happen with the Natami where it would have been huge with all the interest and momentum. The down sides are that you are obligated and have limited room to manuever from the advertised plan with kickstarter. I still like it as a grass roots way to raise production money from the little investors and customers. Less invested money is lost to fees if medium size to large investors would come together and do the planning ahead of time.
Of course not, ASICs, even on an older process (90/65nm) are horrendously expensive for the potential market.
ASICs are the cheapest option with high enough production quantity. Making a few thousand FPGA boards could cost $100,000-$200,000. For double that, maybe less with the right partners, you could be in the range of an ASIC that could lower per unit board costs by maybe 25%-50% and increase performance by several times. Add 1 GB of memory and you are delivering a full slice of Cherry Pi. It's risky but it is a better plan to add Amiga users than Hyperion ever had. I bet they spent millions on software development only to gain a few hundred Amiga users.
FPGAs are more than enough - a ~600Mhz 68020 equivalent is more than enough for any 68k Amiga software that's ever been written.
Is 640kB of memory enough too? The 68k has huge potential that was never developed in performance, code density and ease of use. It can blow in-order Thumb2 ARM out of the water in performance while using less memory and being easier to develop software for. I would love to throw 1GB of memory on board just because it is cheap and so overkill for a 68k Amiga. Such a board wouldn't be a Raspberry Pi killer but it could be a competitor for people who prefer Cherry Pi.
I would say this is a huge over estimate, huge huge HUGE over estimate!!!
It would surprise me a lot if a 68k Cherry pi would sell much at all, probably less than 5000. At least without a full fledge capable CPU with MMU, so that it easily can boot a relevant operating system.
I think you have misunderstood why people buy the raspberry pi, it's not just because it is cheap, it is because it is cheap and fully supported by Linux. Extremely few are interested in a lamed down EC 68k that only can run AmigaOS and maybe uCLinux if you are lucky.
What I'm guessing is that at least 10% of Raspberry Pi purchasers know and have a favorable opinion of either the Amiga or 68k (the 68k may be more popular than the Amiga). These are potential converts with a competive product (even with a somewhat inferior product overall). Such a product would need to be open, compatible and use standards where possible. Improvements need to be made in the CPU, with AmigaOS/AROS and with marketing/image to bring everything up to snuff. There are already developers willing to do the labor of love but some inflow of money could buy more of their time thereby accelerating development.
-
an ASIC that could lower per unit board costs by maybe 25%-50%
What makes you think this?
What do you think that an FPGA to build something comparable to ARCADE or MIST does cost?
What do you think would an ASIC cost?
and increase performance by several times.
Yes this is true.
An ASIC would in theory allow huge performance gain.
But to be able to build an ASIC the design needs to be 100% tested and you need to be 100% sure that you have all good ideas implemented. Also it needs to be clear that doing an ASIC release includes porting to ASIC libraries. This wil also be some work and take weeks if not month.
Before looking at an ASIC I would first try to get the max out of FPGA options.
With todays Vampire600 you get 200 MHz 68020 speed.
With the new ApolloCard we think to get around 600 MHz 68020 speed
With todays better FPGA you could get over double of this. E.g 1200 MHz 68020 Speed.
The new FPGA generation which is on the horizon looks impressive.
My first impression is that performance could again be double t´with them....
I would like to see how good the next gen low cost FPGA will be.
If we could get out of a $15 FPGA 1200 MHz 68020 Speed - then I do not think that an ASIC is really needed for World domination ...
-
Awesome! :D
-
If we could get out of a $15 FPGA 1200 MHz 68020 Speed - then I do not think that an ASIC is really needed for World domination ...
especially an asic once done would age quickly. there would be a window where you can do something with it but it might be narrow. fpga core as i understand it is to an extent reusable in newer generation fpgas.
-
What I'm guessing is that at least 10% of Raspberry Pi purchasers know and have a favorable opinion of either the Amiga or 68k (the 68k may be more popular than the Amiga).
Who are these 10%? You are pulling numbers out of nowhere. Again, people buy R-pi because it has HDMI, is cheap, and runs Linux, fully supported. The company I work for bought a whole bunch of r-pi to plug into big monitors that we use as info displays, the R-pi is perfect as it is tiny, powered by the TV and has HDMI, and because it runs full fledge Linux.
-
May be of interest:
http://www.fleasystems.com/
-
What makes you think this?
What do you think that an FPGA to build something comparable to ARCADE or MIST does cost?
What do you think would an ASIC cost?
It is difficult to come up with good estimates because of hidden costs. An ASIC has more variables and hidden costs. The actual unit cost is based on quantity and demand is difficult to estimate. There may not be that much difference in per unit cost between an FPGA board and an ASIC board but the performance/price goes way up with the ASIC and it's this which is probably needed to win many new Amiga customers and compete with a Raspberry Pi (but not necessary for the niche retro Amiga market). A properly enhanced hard 68k processor would help the 68k to be taken seriously again opening up markets and improving development support. IMO, a more compatible and conservative integer and FPU ISA with a modernized MMU/MPU and probably SIMD unit would be ideal. Modern and compatible sounds easy but it can be more difficult than creating something new.
Yes this is true.
An ASIC would in theory allow huge performance gain.
But to be able to build an ASIC the design needs to be 100% tested and you need to be 100% sure that you have all good ideas implemented. Also it needs to be clear that doing an ASIC release includes porting to ASIC libraries. This wil also be some work and take weeks if not month.
Before looking at an ASIC I would first try to get the max out of FPGA options.
I expect an ASIC needs early planning and experience to organize properly, debug and verify in preparation for an eventual ASIC. That is why I approached Dave@Innovasic who not only understands the embedded market but has experience with a 68k ASIC and may have tools and test cases which could accelerate development in general and ease the work needed to create an ASIC later. He is very creative and I believe would have some good ideas. I think he is somewhat interested as Phoenix shows that you guys are not amateurs with the hardware but there are a lot of loose ends in the business and financing side which are also important. I like Innovasic and Dave but there are also other potential partners which could help with development and marketing resources.
With todays Vampire600 you get 200 MHz 68020 speed.
With the new ApolloCard we think to get around 600 MHz 68020 speed
With todays better FPGA you could get over double of this. E.g 1200 MHz 68020 Speed.
The new FPGA generation which is on the horizon looks impressive.
My first impression is that performance could again be double t´with them....
I would like to see how good the next gen low cost FPGA will be.
If we could get out of a $15 FPGA 1200 MHz 68020 Speed - then I do not think that an ASIC is really needed for World domination ...
This is more of a philosophical quandary. Will people be satisfied with a slower but adequate performance CPU and more efficient OS? I think history shows the answer so far is clearly no. The majority of people would like to have the highest performance processor possible or the most performance/price as affordability becomes a factor.
Who are these 10%? You are pulling numbers out of nowhere. Again, people buy R-pi because it has HDMI, is cheap, and runs Linux, fully supported. The company I work for bought a whole bunch of r-pi to plug into big monitors that we use as info displays, the R-pi is perfect as it is tiny, powered by the TV and has HDMI, and because it runs full fledge Linux.
Haven't you heard that 97.3% of statistics were pulled out of thin air or inaccurate? Of course it's a guess. Please poll and calculate unbiased statistics and get back with me. Once we know the exact demand we can calculate the number of boards to make and investors will trust your results so much that they will pull their money out of no risk negative interest rate investments and invest in a sure thing like the Amiga :P.
May be of interest:
http://www.fleasystems.com/
I wandered across that site several years ago as I was search for something Amiga related. I was surprised when my search brought up some Dave Haynie quote like this:
NEVER EVER mess with a PCB jumper you don't understand, even if it's labelled "SEX AND FREE BEER".
I couldn't find it anymore so maybe they took it down.
-
You must first tell me what the poll is supposed to be about, without MMU it will have extremely limited use. With a proper implementation that is compatible and has MMU you could get it to run NeXTStep, Plan9, MiNT, Linux, NetBSD, OpenBSD, SunOS etc which people would actually be interested in, especially if it was mindbogglingly fast. Without MMU, there are already plenty of hardware alternatives, and none of them very popular.
So what is your idea?
EDIT: I see now that Gunnar says Apollo has MMU, which makes it a lot more interesting.
-
You must first tell me what the poll is supposed to be about, without MMU it will have extremely limited use. With a proper implementation that is compatible and has MMU you could get it to run NeXTStep, Plan9, MiNT, Linux, NetBSD, OpenBSD, SunOS etc which people would actually be interested in, especially if it was mindbogglingly fast. Without MMU, there are already plenty of hardware alternatives, and none of them very popular.
So what is your idea?
EDIT: I see now that Gunnar says Apollo has MMU, which makes it a lot more interesting.
The MMU is one of the areas we need to talk about and work out. Gunnar's MMU is very simple and incompatible with the 68k MMU in the 68030-68060. The 68030 MMU is very flexible and has some interesting ideas but is far from modern MMUs. The 68040 and 68060 MMUs are similar and very capable but the page sizes only go up to 8kB which is small and not optimum for modern large memory sizes. Enlarging the page sizes would break compatibility with the 68040 and 68060 MMU and there may be other changes necessary to modernize it. ThoR or Gunnar could probably give more details as the MMU is not my strong point. The 68060 MMU allows virtualization (virtual addresses and physical to virtual translation) which is a great modern feature but it has a cost. All cached addresses which may have a virtual address need to be flushed on context switches which has overhead. The 68060 may require this already with it's branch cache. Memory performance can degrade with many page misses from accessing memory in a dispersed or random way. More hardware can make up for this problem but at a cost. The CPU pipeline can increase by 1 stage depending on how the MMU is designed also. Gunnar and Jens know the best way to make a modern MMU and ThoR could help with the design. Gunnar is resistent to a more advanced MMU with virtual addresses in an FPGA because of the cost of performance and because the Amiga doesn't need it. The overhead of such an MMU as a percentage of performance is much smaller in an ASIC and the advantages for an open platform 68k board which would support multiple OSs is more compelling. This still leaves the question of how compatible an updated and modernized 68k MMU could be. Some changes to existing 68060 MMU support in the OSs which support the 68k would be necessary for optimal performance at least and maybe even to be usable. Personally, I think an MMU which supports virtual addresses is an important modern feature which would be important if competing against the Raspberry Pi with an ASIC. Embedded applications use memory protection more and more all the time but I expect the extra performance to be more important than virtual addressing.
As for a poll, the questions might be something like this:
Do you know about the AmigaOS, AROS or MorphOS?
If yes, what is your opinion of AmigaOS, AROS or MorphOS?
1) Very favorable
2) Somewhat favorable
3) Indifferent or no opinion
4) Somewhat unfavorable
5) Very unfavorable
Do you know about the 68k CPU?
If yes, what is your opinion of a more modern 68k CPU with MMU, FPU and SIMD unit?
1) Very favorable
2) Somewhat favorable
3) Indifferent or no opinion
4) Somewhat unfavorable
5) Very unfavorable
Only Raspberry Pi owners could be asked and even the wording of the questions could introduce bias. Data from international regions would probably vary (Asia likely would not be good for the Amiga or 68k). The results would be interesting although I wouldn't put to much confidence in them. My point was that a fraction of the Raspberry Pi market is a huge number of users (1%=50,000 users currently and growing). Hyperion likely spent over a million and maybe millions of U.S. dollars to gain a few hundred users which are not enough to sustain them with software or hardware purchases. It's likely that we could bake ourselves a cherry Pi and grab a slice of a bigger pie for less cost.
-
Being an 020 CPU do you need a special 060 library to fool some programs that will only run when an 060 is detected?
-
The 68030 MMU is very flexible and has some interesting ideas but is far from modern MMUs. The 68040 and 68060 MMUs are similar and very capable but the page sizes only go up to 8kB which is small and not optimum for modern large memory sizes. Enlarging the page sizes would break compatibility with the 68040 and 68060 MMU and there may be other changes necessary to modernize it.
Matt is 100% correct here.
The 030 and 040 MMUs are first of all - incompatible.
From a todays view point both are not perfect and you would want to improve them with a new MMU design.
And of course your "ideal" MMU very much depends on what you want to do.
The "ideal" MMU for Linux looks different than the "ideal" MMU for AMIGA OS would look like.
I can not image that someone will seriously want to run Linux on 68k
But of course the beauty of the FPGA is that - one could create in theory 2 MMU designs -
one tuned for AMIGA OS and one tuned for LINUX And the people can pick their Core version for runnig in their FPGA.
-
There are plenty of us running Linux on m68k, and m68k is well supported by the Linux kernel and the GNU tool chain, in parallel with ColdFire. If you manage to provide a modern and fast, and well documented 68k CPU, you will quickly find Linux running on it, as well as NetBSD.
-
For sake of compatibility for those who want hardware to run old m68k OSes (NeXTStep, Plan9, A\UX, MacOS...) I think compatibility with 68040 is favourable. It may be worthwhile to check with people over at http://www.nextcomputers.org/ if they would be interested.
-
Being an 020 CPU do you need a special 060 library to fool some programs that will only run when an 060 is detected?
This would not be a good idea in general because Phoenix has the 64 bit integer MUL*.L and DIV*.L instructions in hardware and detecting a 68060 may use slower code which would avoid them. It would be a better idea if MOVE16 was implemented also (not difficult). Most code that detects for a 68060 needs a 68060 compatible FPU or MMU which Phoenix doesn't currently have. In some specific cases, changing the SysBase->AttnFlags may get some programs working but this would more commonly result in a guru. A program that changes SysBase->AttnFlags is trivial. There are other programs that would detect for a 68060 in other ways that would not be so easy to fix. Most 68060 optimized and compiled code which does not use the FPU or MMU should work on Phoenix (and a 68020) right now.
There are plenty of us running Linux on m68k, and m68k is well supported by the Linux kernel and the GNU tool chain, in parallel with ColdFire. If you manage to provide a modern and fast, and well documented 68k CPU, you will quickly find Linux running on it, as well as NetBSD.
I agree. Frank Wille is a NetBSD developer (Amiga/PPC ports) and expressed interest in a 68k version of Phoenix with MMU. The low memory footprint could make it useful for small servers. The Amiga and BSD are almost opposite ends of the spectrum as far as security so supporting Unix (and other high security OSs like Plan9) would attract a wider audiance.
For sake of compatibility for those who want hardware to run old m68k OSes (NeXTStep, Plan9, A\UX, MacOS...) I think compatibility with 68040 is favourable. It may be worthwhile to check with people over at http://www.nextcomputers.org/ if they would be interested.
There is little difference between the 68040 and 68060 MMU as already stated. The 68060 MMU has a few more restrictions. Most OSs abandoned the 68k before support for the 68060 MMU was added so a 68040 MMU interface would be more compatible. Adding support for an updated MMU would likely require more changes than from 68040 MMU to 68060 MMU. Maybe some kind of compatibility layer could be added in between to get old OSs working and to have a working system when enabling old support.
-
i am asking around in various relevant communities, it would be nice if the http://www.apollo-core.com pages could say a little more about compatibility (68020 instructions) and about your MMU plans.
-
i am asking around in various relevant communities, it would be nice if the http://www.apollo-core.com pages could say a little more about compatibility (68020 instructions) and about your MMU plans.
when you say "communities" how many people are these roughly?
what hardware systems are they using exactly?
-
ASICs are the cheapest option with high enough production quantity. Making a few thousand FPGA boards could cost $100,000-$200,000. For double that, maybe less with the right partners, you could be in the range of an ASIC that could lower per unit board costs by maybe 25%-50% and increase performance by several times. Add 1 GB of memory and you are delivering a full slice of Cherry Pi. It's risky but it is a better plan to add Amiga users than Hyperion ever had. I bet they spent millions on software development only to gain a few hundred Amiga users.
In 2009 gunnar von boehn promised something like raspberry pi.
Wonderful NatAmi with cpu faster than g4 and graphics better than ps3, for 100 euros only.
Even with the later change for graphics ps2 level only, it was a good plan.
if only NatAmi existed in reality, NatAmi would have had great success.
Unfortunately in 2015, as in 2009, gunnar has nothing working and ready to sell.
kleinegun where is my natami?
-
kleinegun where is my natami?
(http://indiawires.com/wp-content/uploads/2013/11/user-stop.jpg)
-
This would not be a good idea in general because Phoenix has the 64 bit integer MUL*.L and DIV*.
Interesting as I have tried a few demos that will not run without an 060 and wont continue and will produce an error asking for an 060.
Will hold on to my 060 for now if there is no work around. Which is a shame as the 020 core could be a lot faster than my 80MHz 060.
-
when you say "communities" how many people are these roughly?
what hardware systems are they using exactly?
I need to do counting too?
Well, there's Amiga and Atari peeps obviously, running you know what. There's the NeXTStep die hards using NeXTStation and Cubes, there's people who enjoy firing up unixen for old (*gasp*) Apollo computers, there are people keeping their old macs alive for A\UX and ditto for old SunOS. Then are there people like me who happily run Linux and *BSD on anything that has a capable m68k inside, from old Macs, Amigas, Ataris, Motorola VME boards... anything. How many all these add up to? No idea, but certainly way lot more than Amiga folks alone.
-
The first answers at NeXT forum is that compatibility with 68030/882 or a full 68040 is needed, which is pretty much what I expected. Also the rumour was that apollo core is mostly vapourware, only 68000 capable, and that among all the 68k cores, the TG68 is the most preferable anyhow :) I can understand the centiment, how can one trust people with only background in Amiga to do a capable 68k MMU for example. I would say the Apollo team could benefit greatly by pulling in people from other plattforms to chime in, especially Atari people are easily available.
-
I need to do counting too?
Well, there's Amiga and Atari peeps obviously, running you know what. There's the NeXTStep die hards using NeXTStation and Cubes, there's people who enjoy firing up unixen for old (*gasp*) Apollo computers, there are people keeping their old macs alive for A\UX and ditto for old SunOS. Then are there people like me who happily run Linux and *BSD on anything that has a capable m68k inside, from old Macs, Amigas, Ataris, Motorola VME boards... anything. How many all these add up to? No idea, but certainly way lot more than Amiga folks alone.
The question was how many people use what computer system.
If you have 1000 people using an A1200 and wanting to upgrade then it can make sense to design a new accelerator card for them.
If you have 40 people using system A, 30 people using system B, 50 people using symtem C, 60 people using system D .... and so on ... then you might in total have many people but - but the number of different upgrade cards to design would kill you.
Can you give me a feeling how many people and how many cards you talk about?
-
Kolla,
You have to see we test every card with a real system,
If got an A1000, two A2000, an A4000, three A500, two A300/A600, two A1200, a CD32 here to be able to test the Core and bus controllers on different systems.
And the above is only my test setup - the others in the team also have many systems to test.
There is a logical limitations how many more tests system I can setup before my beloved wife will kick me.
For the Linux fans how much sense would it make to hold out for the upcoming stand alone system?
-
The MMU is one of the areas we need to talk about and work out. Gunnar's MMU is very simple and incompatible with the 68k MMU in the 68030-68060. The 68030 MMU is very flexible and has some interesting ideas but is far from modern MMUs. The 68040 and 68060 MMUs are similar and very capable but the page sizes only go up to 8kB which is small and not optimum for modern large memory sizes.
We are not talking about modern applications here. We are talking about Amiga applications. Still, the page size for the intels is 4K, with optional huge page support. The 68030 design could offer that out of the box ("early termination descriptors"). Enlarging the page sizes would break compatibility with the 68040 and 68060 MMU
Compatibility with *what*? Programs that hack on the MMU should go anyhow. As far as other Oses are concerned, I cannot tell you what they do, but one way or another, the core requires some software support in first place, in the same way the 68060 required software support. As far as the mmu.lib is concerned, every page size works. (Provided it is a power of two). Still, 4K pages are - for Amiga - really not too bad. In the end, I would probably not go for a complete 68060 MMU in first place, but rather emulate parts of its functionality in software in the same way the 68060 emulates parts of the chip in software. Thus, I would probably only have the ATC logic on chip, and would do the table-walk in software (i.e. that part that collects the descriptor from RAM). Such a construction could emulate any MMU from 68851 to 68060 with a bit of software support. ThoR or Gunnar could probably give more details as the MMU is not my strong point. The 68060 MMU allows virtualization (virtual addresses and physical to virtual translation) which is a great modern feature but it has a cost.
That is an elementary feature that goes for all MMUs right away. All cached addresses which may have a virtual address need to be flushed on context switches which has overhead. The 68060 may require this already with it's branch cache.
No, that's rather a matter of whether the cache is addressed by physical or logical addresses. If it is addressed by physical addresses, context switches are free. Only the relatively slow 68030 and 68020 caches were logically indexed, everything above that was physically indexed, and hence, context switches do not require a cache flush on these processors. Memory performance can degrade with many page misses from accessing memory in a dispersed or random way. More hardware can make up for this problem but at a cost. The CPU pipeline can increase by 1 stage depending on how the MMU is designed also.
The major problem with a MMU is really the enlarged pipeline, which limits throughput. Gunnar and Jens know the best way to make a modern MMU and ThoR could help with the design. Gunnar is resistent to a more advanced MMU with virtual addresses in an FPGA because of the cost of performance and because the Amiga doesn't need it. The overhead of such an MMU as a percentage of performance is much smaller in an ASIC and the advantages for an open platform 68k board which would support multiple OSs is more compelling.
Jens is making good hardware designs, but I don't believe he has the knowledge in CPU design. Gunnar has, I can certainly give a broad design of a MMU that is powerful enough to emulate everything with proper software support, and design the system software for that. But whether such a design is performing well and worth implementing in an FPGA is really something only Gunnar can answer. This still leaves the question of how compatible an updated and modernized 68k MMU could be.
See above. I have a small design in my back-head somewhere that is a software-driven MMU capable enough to emulate the 68851 up to the 68060. But, as the 68060, it requires an additional support library. Some changes to existing 68060 MMU support in the OSs which support the 68k would be necessary for optimal performance at least and maybe even to be usable. Personally, I think an MMU which supports virtual addresses is an important modern feature which would be important if competing against the Raspberry Pi with an ASIC.
Actually, a MMU that does not distinguish logical and physical addressing is hardly ever an MMU. Embedded applications use memory protection more and more all the time but I expect the extra performance to be more important than virtual addressing.
All the nice features like kickstart remapping, zero-page remapping or MuRedox require a logical addressing that is different from physical addressing. You could hard-code such cases in the FPGA, but how ugly a design is that? It would be "Amiga only". It's not the type of design I would call "elegant" or "future proof" (for whatever "future" and "Amiga" could mean together, but hey, if you design something as an engineer, you want to make it right, ok?)
-
All the nice features like kickstart remapping, zero-page remapping or MuRedox require a logical addressing that is different from physical addressing. You could hard-code such cases in the FPGA,
Good examples.
You can solve this in different ways.
It really depends on what feature you focus on.
For example:
1) You could have a very simple flat design where the whole memory is mapped in 4K pages.
2) You could have a hirarchical design with for example 512 KB size top level entries, and below 4 sub level entries.
3) You could implement this not with an MMU map but with a number of programmable mapping registers. Just like the EC chips did have them. You could make those register really flexible to allow programming of mapping or snooping of any size. For example you could say I have here at $54321 and memory array of size 11 bytes I want to snoop any access to it.
Option 3) is very useful for programming, testing and debugging.
I use this feature in Phoenix regularly.
For a general purpose Unix compatible MMU design option 2 will be better than option 1.
But again there are many detail questions. How many ERATs / Cache entries are needed to be able to run bigger unix programs really well?
The old 68K MMU have in my humble opinion only enough cache entries to run programs of their time. The could ran well typical 90th application - but for todays staandards I would increase the number of cache entries.
-
Could someone record a video with Prayer2 on Vampire?
(http://www.szulu.host.sk/amiga/obrazki/prayer2.jpg)
http://aminet.net/mus/play/Prayer2.lha
http://aminet.net/dev/gui/opentriton-usr.lha
http://aminet.net/search?query=popupmenu
-
2) You could have a hirarchical design with for example 512 KB size top level entries, and below 4 sub level entries.
I wouldn't go for a hierarchy, it's all complicating matters. A flat page table within which the MMU finds entries by trying several hash algorithms to find a suitable table entry would be entirely sufficient. Everything else, like filling the page table, or replacing descriptors in the page, can be done entirely in software. This software can do the table walk and emulate whatever 68K MMU there is.
But no matter what - that's not the problem at this point. The problem at this point is making a hobby project a product. This requires a vendor, and a salesmen, and some funding. I cannot deliver any of this. The old 68K MMU have in my humble opinion only enough cache entries to run programs of their time. The could ran well typical 90th application - but for todays staandards I would increase the number of cache entries.
I don't have a problem with a larger ATC, but that's all not the problem. Actually, it only has to run programs of its time - isn't that its primary use? But see above - first things first.
-
if this crap natami have to be useful for anything other than amiga os, it must have MMU.
This MMU does not have to be existing 68k MMU compatible, of course.
kleine-gun where is my natami?
-
if this crap natami have to be useful for anything other than amiga os, it must have MMU.
This crap natami has a standard 68060 CPU on board, and hence a standard 68060 MMU.
This MMU does not have to be existing 68k MMU compatible, of course.
kleine-gun where is my natami?
This crappy natami is on my crappy desk. Here you go.
-
if this crap natami have to be useful for anything other than amiga os, it must have MMU.
This MMU does not have to be existing 68k MMU compatible, of course.
kleine-gun where is my natami?
if you really think that your "crap" motivates anyone to use PPC you are on the wrong planet
-
@olaf
thats a false flag op.
-
Gunnar, providing cards for old computers was not in my agenda. While building acc cards for old systems is pretty cool, it's the stand alone systems that are of main interest, at least for me. The question is if you can reimplement a lot of old hardware using an FPGA, so that the old operating systems will be able to run on them.
-
Gunnar, providing cards for old computers was not in my agenda. While building acc cards for old systems is pretty cool, it's the stand alone systems that are of main interest, at least for me. The question is if you can reimplement a lot of old hardware using an FPGA, so that the old operating systems will be able to run on them.
Not sure I understand the question.
If we would not put SAGA into the FPGA how could we run Amiga OS?
-
Not sure I understand the question.
If we would not put SAGA into the FPGA how could we run Amiga OS?
i think the only sensible might be is licensing the core to other fpga hardware providers for the time being. as example, if not for vampire the core woulnt probably be available to testers-users till now. doing everything by yourself will drain your capabilities quickly. this way also the support for other systems could be hierarchically outsourced to interested parties.
-
Gunnar, providing cards for old computers was not in my agenda. While building acc cards for old systems is pretty cool, it's the stand alone systems that are of main interest, at least for me. The question is if you can reimplement a lot of old hardware using an FPGA, so that the old operating systems will be able to run on them.
Offering accellerators using A600 or A500 is only the first step. The Vampire is too small for the whole chipset but the card for A500 will be big enough and has both LAN and its own modern interface to monitors so processor, RTG and the chipset will then run on the card and the host hardware will be only used for keyboard and some of the old ports. The idea is to have something soon and then (after that) continue with developing a standalone hardware (that is more complicated, needs more drivers and so on).
-
i think the only sensible might be is licensing the core to other fpga hardware providers for the time being. as example, if not for vampire the core woulnt probably be available to testers-users till now. doing everything by yourself will drain your capabilities quickly.
Our new cards are in testing already ....
this way also the support for other systems could be hierarchically outsourced to interested parties.
I do not see the scaling benefit of this.
If you license the core to 3 different parties then this does not save you time this creates more work for you. You have to support them. Each partner might use a different FPGA, different memory. So you need to help them to interface and to test/fine tune the memory controller.
Even is you provide standard industry bus interfaces - as Apollo does.
They will have many questions which you need to answer.
I have no secretary which could answer all these customer questions.
Therefore to be honest - I do not think that this will save me time but cost me time.
-
@ppcamiga1
knock it off. now. this is your only warning. keep up with the abusive and trolling posts and you'll earn a vacation from the site.
-- eliyahu
-
I have no secretary which could answer all these customer questions.
one day you might need one anyway;)
but sure you know best yourself.
-
Everything else, like filling the page table, or replacing descriptors in the page, can be done entirely in software. This software can do the table walk and emulate whatever 68K MMU there is.
I like the idea of a software solution but I think it could add an extra workload for the CPU.
-
I like the idea of a software solution but I think it could add an extra workload for the CPU.
It's a matter of finding the right balance, and the size of the cache. The current core already requires software support for integer arithmetic and - quite like the 68060 - does not suffer from that because only exotic instructions require emlation that are rarely ever needed.
Consider an ATC of 256 entries, 4K per entry. This is already pretty small. The core could then address 1MB of memory without ever requiring a table walk. Put this into perspective to the typical Amiga program, probably at one tenth of this size.
Thus, the core would at worst initiate a table walk when loading a program.
Anyhow, this is all theory. I'm not saying that anyone should focus on this right now. There are more serious matters.
-
If you license the core to 3 different parties then this does not save you time this creates more work for you. You have to support them. Each partner might use a different FPGA, different memory. So you need to help them to interface and to test/fine tune the memory controller.
Even is you provide standard industry bus interfaces - as Apollo does.
They will have many questions which you need to answer.
I have no secretary which could answer all these customer questions.
Therefore to be honest - I do not think that this will save me time but cost me time.
+1
-
+1
To prevent misunderstandings.
There is a lot of proting work going on already.
Right now people port/test the core to the following systems already.
Vampire-600 - CPU Accelerator for A600 - Status working
Vampire-500 - CPU Accelerator for A500 - Status testing
Apollo-Phoenix - CPU Accelerator for A500 - Status testing
HighEndC5 - Standalone System - Status porting
Natami - everyone knows this - Status porting
Vampire 2 - CPU Acclerator - Status in delevopment
As you see we support already 5 FPGA systems, and the 6th is current in development
I think we are already quite thin spread with our man power to support all 6 systems in parallel
-
It's a matter of finding the right balance, and the size of the cache. The current core already requires software support for integer arithmetic and - quite like the 68060 - does not suffer from that because only exotic instructions require emlation that are rarely ever needed.
Consider an ATC of 256 entries, 4K per entry. This is already pretty small. The core could then address 1MB of memory without ever requiring a table walk. Put this into perspective to the typical Amiga program, probably at one tenth of this size.
Thus, the core would at worst initiate a table walk when loading a program.
Anyhow, this is all theory. I'm not saying that anyone should focus on this right now. There are more serious matters.
In an AMP context, your idea seems very promising. Especially as the architecture of the Amiga should facilitate this development.
And no, I have not forgotten the many discussions around a possible AMP based solution. In fact, I quietly waiting it.
-
This crap natami has a standard 68060 CPU on board, and hence a standard 68060 MMU.
This crappy natami is on my crappy desk. Here you go.
gunnar von boehn promised NatAmi faster than powerpc.
I do not want NatAmi with 060.
I want NatAmi faster than g4 with PS2 level graphics, for 100 euros only.
gunnar promised that in autumn 2009, everyone will be able to buy it.
gunnar where is my NatAmi?
-
@ppcamiga1
you were warned to stop trolling in this thread, and you ignored it. enjoy your two-week break.
-- eliyahu
-
@ppcamiga1
you were warned to stop trolling in this thread, and you ignored it. enjoy your two-week break.
-- eliyahu
Thank you!
-
Thank you!
Yes Thank you!
-
Sometimes people make moderating decisions too easy. ;)
:banana: :banana: :banana: :banana: :banana: :banana: :banana:
:pint: :pint: :pint: :pint: :pint: :pint:
-
@ThoR
I used the term virtual address instead of logical address, hoping non-technical people would understand it better. I guess I won't be writing any technical manuals on the MMU.
I wouldn't go for a hierarchy, it's all complicating matters. A flat page table within which the MMU finds entries by trying several hash algorithms to find a suitable table entry would be entirely sufficient. Everything else, like filling the page table, or replacing descriptors in the page, can be done entirely in software. This software can do the table walk and emulate whatever 68K MMU there is.
So would support code be loaded before boot which would trap when 68040 MMU instructions not in hardware were used? Then offer a supervisor space library interface to the same code (like fpsp.resource but supervisor only) which can be used to reduce the trap overhead? This could make it easy to get an OS using a 68040 MMU up and running and then slowly replace the trapped MMU instructions?
-
gunnar von boehn promised NatAmi faster than powerpc.
I do not want NatAmi with 060.
I want NatAmi faster than g4 with PS2 level graphics, for 100 euros only.
gunnar promised that in autumn 2009, everyone will be able to buy it.
Gunnar overpromised many things but I don't remember any "for 100 euros only" promise. Maybe you are referring to "CPU only"?
And the deal with "faster than g4" was actually "Mhz for Mhz faster than G4".
That means a 100 Mhz Natami/Apollo would be faster than a 100Mhz G4. A 300Mhz Natami/Apollo would be faster than a 300Mhz G4. And a 400Mhz Apollo/Natami would be faster at copying memory from Point A to Point B than a 2200Mhz G4 due to the spectacularly bad memory interface endemic to all publicly available PPC processors.
If you are going to criticize someone, fine, but be truthful about it.
-
Not sure I understand the question.
If we would not put SAGA into the FPGA how could we run Amiga OS?
Exactly, and for Amiga (and Atari) this is pretty much done deal, FPGA implementations of chipsets exists, but I don't this is the case for other m68k systems.
@matthey, a "cherry pi" would need an FPGA anyhow to be useful for AmigaOS. Price wise, what is more expencive you think, a bigger FPGA to hold both CPU and chipset and whatnot, or an ASIC for CPU and a "cheaper" FPGA for chipset++?
-
Exactly, and for Amiga (and Atari) this is pretty much done deal, FPGA implementations of chipsets exists, but I don't this is the case for other m68k systems.
@matthey, a "cherry pi" would need an FPGA anyhow to be useful for AmigaOS. Price wise, what is more expencive you think, a bigger FPGA to hold both CPU and chipset and whatnot, or an ASIC for CPU and a "cheaper" FPGA for chipset++?
It should be possible to bake the Amiga chipset and possibly even other chipsets into the ASIC, although a small FPGA for a chipset would be more flexible. I believe the power could be switched off to the chipsets if someone wanted a CPU only. Then again, it would be useful if the CPU came with a chipset, more I/O support like ethernet and USB, memory controller and even a small amount of memory. One of the reasons ARM SoCs are used so much is that they are convenient, cheap to build a board and low power. If there was a decent 68k SoC on the market, I bet there would be a slew of new Amiga hardware projects pop up over night.
-
I'm curious if old MacOS 8 under Shapeshifter has been tested on Vampire600?
-
Exactly, and for Amiga (and Atari) this is pretty much done deal, FPGA implementations of chipsets exists, but I don't this is the case for other m68k systems.
If you run BSD or Linux then you are not banging the chipset anyway.
So where is the point to have diffrent chipset for these users?
Isn't one chipset which is supported all they need?
-
Of course both BSDs and Linux are banging the chipset, how else would they provide screen output and sound? Of course these also have the advantage that they will be able to support and make use of SAGA too, when that time comes. Other OSes are not so fortunate, and require that people replicate their old chipsets in the FPGA.
-
Of course both BSDs and Linux are banging the chipset,
The point is on BSD and Linux all software goes through a driver - there is nothing banging the chipset directly. So on BSD or LINUX it does not matter what hardware you have. The same is true for MAC-OS.
For ATARI and AMIGA the story is different. An AMIGA without AMIGA chipset is no AMIGA ...
-
So would support code be loaded before boot which would trap when 68040 MMU instructions not in hardware were used? Then offer a supervisor space library interface to the same code (like fpsp.resource but supervisor only) which can be used to reduce the trap overhead? This could make it easy to get an OS using a 68040 MMU up and running and then slowly replace the trapped MMU instructions?
Look, you are asking a lot of questions on concrete software implementation in a situation where even requirements and use cases are not strictly defined. Thus, it is really a bit premature to say anything, given that no single thought has been wasted on an actual MMU in the Phoenix.
If you want me to cook something up in a minute, I would say that a typical solution would possibly make the CPU trap in case it does not find its descriptor in the cache. A mmu support package (mmusp) would catch this exception, perform the table walk as the 68K MMUs would do, replace descriptors in the cache, and resume operation. In case it does not find the descriptor in the table, it would initiate the bus error from the software side.
There are not really many MMU instructions that would need to be trapped. Actually, none of them are user accessible, so none of them require - strictly speaking - any trapping. You would probably have to emulate the TTx registers to allow exec to start up, probably even as a no-op, but that's only an implementation detail.
What then could happen is that is extensive mmusp could be replaced by something simpler, for example the mmu.library, as soon as it comes into play.
But anyhow, these are all rough design ideas without really having them checked, and whether they might survive contact with reality is another story.
One way or another, at this point I would rather prefer to get the current core done "as a product" (i.e. can be bought as expansion card in stores). Since that's all on an FPGA, it shouldn't really cause too much trouble replacing that in the future, should the card be successful, should there be enough users, should Gunnar find enough time for the design... Many "if's" in this equation, so please, I don't think it makes much sense to discuss this right now.
-
It should be possible to bake the Amiga chipset and possibly even other chipsets into the ASIC, although a small FPGA for a chipset would be more flexible.
Maybe it makes sense to sum up the difference:
CPU
in FPGA ~ 600 Mhz 68020 Speed
in Very Good FPGA ~ 1200 Mhz 68020 Speed
+ needed investment to develop an FPGA system is low - some hundred to maybe thousand $ to get prototype
+ Bugs can be fixed in the field
CPU
in low end ASIC ~ 1000 MHz 68020 Speed
in high end ASIC ~ 5000 MHz 68020 Speed
- needed investment is huge for high end Asic the price for prototype can be in range of $200,000
- if there is a bug then the ASIC can not be fixed.
- To fix a bug again $100,000 need to be invested.
GFX Chipset
If you do the chipset well then you can get with todays entry level FPGA already super performance.
16bit CD quality audio is no problem.
FULL HD video output is no problem, 24bit truecolor is no problem,
If you do it right then having 100 times DMA performance compared to AGA is no problem with todays entry level FPGAs.
an ASIC could again improve over this.
But would have huge cost and huge risk.
I'm personally happy with FULL HD - I do not need 4K display ...
In regards of the chipset I would certainly prefer to use an FPGA to keep the risk and investments lower and to have the possibility to improve the chipset if we want to.
-
Maybe it makes sense to sum up the difference:
CPU
in FPGA ~ 600 Mhz 68020 Speed
in Very Good FPGA ~ 1200 Mhz 68020 Speed
+ needed investment to develop an FPGA system is low - some hundred to maybe thousand $ to get prototype
+ Bugs can be fixed in the field
The biggest advantage I can see is that it would make it easier to support different MMU types and switch between them. An R4000 style MMU where the CPU does the page walking could be added for those that want it, or an 030/040/060 MMU could be used by those who wanted to be compatible with old software.
I personally only want an FPGA that runs code that requires an 060 CPU/FPU/MMU. For me any other instructions or functionality is a big negative. It would be awesome if someone could do 040/030/020/010 & 000 implementations too. If it's not this project then hopefully some day someone will do it.
-
As you see we support already 5 FPGA systems, and the 6th is current in development
I think we are already quite thin spread with our man power to support all 6 systems in parallel
I was wondering why you take on so many things at once.Maybe it would be better to work on just one system at a time, test it and put it out -then work on the next one?
-
I was wondering why you take on so many things at once.Maybe it would be better to work on just one system at a time, test it and put it out -then work on the next one?
This is easy to explain.
There are several people involved in the project
Igor Majstorovic, did develop the Vampire600 accelerator card for the A600, and the Vampire500 card for the A500. These cards to exist already.
Jens Künzer owns a Terasic stand alone FPGA system.
This system offer great performance for price. The system was sold for $90
The FPGA is fast enough for 600 MHz 68020 speed.
The sys tem has audio and video out.
And comes with dual fast memory controller and 256 MB fastmem.
So he wants to bring uo this one.
Christoph Hoehne has designed the Apollo-Phoenix Cyclone 5 CPU accelerators for A500/A1000/A2000. This is a great system not only able to provide a very good speed up, but also includes GFX card update and more features.
He of course does the bringup of this card.
Thomas Hirsch - is probably well known as the inventor of the NATAMI currently tests the integration of Phoenix CORE in the NATAMI as option for people instead using an 68060.
-
Christoph Hoehne has designed the Apollo-Phoenix Cyclone 5 CPU accelerators for A500/A1000/A2000. This is a great system not only able to provide a very good speed up, but also includes GFX card update and more features.
He of course does the bringup of this card.
Thomas Hirsch - is probably well known as the inventor of the NATAMI currently tests the integration of Phoenix CORE in the NATAMI as option for people instead using an 68060.
two questions!.
1. So when will this stand-alone system be possible to buy. ?
2. "Thomas Hirsch - is probably well known as the inventor of the NATAMI currently tests the integration of Phoenix CORE in the NATAMI as option for people instead using an 68060."
- So that means he is working on natami, today. ? Extremly intresting please give us a timeframe when this will be something me as a end user can buy. ??
-
It would be funny if progress stopped because we needed to make it Linux compatible. Then in 5 years we will still be using 030s and 060s. No FPGA accelerators.
-
two questions!.
1. So when will this stand-alone system be possible to buy. ?
The terrasic stand alone system you can buy already today.
They are professional FPGA boards not done buy us.
The NATAMI was sold to a limited number of users.
If /When Thomas will sell again - I do not know and can not answer.
But the option to have more than 68060 CPU power and at the same price reduce the cost as 68060 does not need to be bought, makes sense.
I assume both Chis and Igor could /might also create a stand alone system based on their current designs with very interesting features..
This would logically make sense - but no timeline yet.
t
- So that means he is working on natami, today. ? Extremly intresting please give us a timeframe when this will be something me as a end user can buy. ??
He is obviously working with it.
When/or if at all they will be available I can not answer.
It hardly makes sense now to speculate.
First of all you should give him the time to finish the integration.
-
CPU
in FPGA ~ 600 Mhz 68020 Speed
in Very Good FPGA ~ 1200 Mhz 68020 Speed
+ needed investment to develop an FPGA system is low - some hundred to maybe thousand $ to get prototype
+ Bugs can be fixed in the field
CPU
in low end ASIC ~ 1000 MHz 68020 Speed
in high end ASIC ~ 5000 MHz 68020 Speed
- needed investment is huge for high end Asic the price for prototype can be in range of $200,000
- if there is a bug then the ASIC can not be fixed.
- To fix a bug again $100,000 need to be invested.
This post hopefully clears everything up :)
We are going to have super-duper Amigas with minimum risk and investment folks.
Sure, we could have insanely fast Amigas, and 5 GHz does sound temping, but it is a HUGE step. And requires an amount of money that goes far beyond enthusiasm. Unless one of us wins some crazy lottery :)
So please, let us appreciate what the team is doing right now and hold the unrealistic suggestions unless someone knows an eager investor :)
-
The terrasic stand alone system you can buy already today.
They are professional FPGA boards not done buy us.
The NATAMI was sold to a limited number of users.
If /When Thomas will sell again - I do not know and can not answer.
But the option to have more than 68060 CPU power and at the same price reduce the cost as 68060 does not need to be bought, makes sense.
.
I take it you know about this?
A1200 accelerator interface (http://www.a1k.org/forum/showthread.php?t=42077)
-
CPU
in low end ASIC ~ 1000 MHz 68020 Speed
in high end ASIC ~ 5000 MHz 68020 Speed
- needed investment is huge for high end Asic the price for prototype can be in range of $200,000
- if there is a bug then the ASIC can not be fixed.
- To fix a bug again $100,000 need to be invested.
I don't know what you mean with low end ASIC but you also have the structured ASICs, now most of the time using one-mask programmable ASIC. Examples I know of are eASIC (http://www.easic.com) and Triad Semiconductor (http://www.triadsemi.com). They have power consumption advantages over FPGA and startup cost over full custom (standard cell) ASICs. Speed advantages over FPGA has to be evaluated.
-
New video to watch.
https://www.youtube.com/watch?v=B69-EA3XOBM
-
sorry, but this cant be real time, none is able to use computer at this speed.
-
sorry, but this cant be real time, none is able to use computer at this speed.
LOL i have a friend who writes C code in this speed or faster.
-
Perhaps the user has also been flashed with a new core :)
-
LOL i have a friend who writes C code in this speed or faster.
Is the code any good though?
-
Insert random comment:
Where is Chuck Norris when you need him?
-
Insert random comment:
Where is Chuck Norris when you need him?
Chuck Norris owns a Natami, but he'll kick your ass if you ask him about that project. :hammer:
Hey, at least Gunnar is trying to keep everybody informed about what he is into.
What's with all the ancillary questions?
-
What is the predicted price for the Vampire?
I have decided that the biggest technical problem for the Vampire is...
I don't own an A600 and never have. :)
In fact I have been trying to think up an excuse to buy an accellerator for An A500 or A2000 but I have no desire to accelerate those machines. I only use old OCS/ECS machines to be 100000000% compatible with old games.
Seriously if I was going to buy an accellerator for an old ECS/OCS Amiga it would be for one of my A3000s. My A3000 has an absolutely wonderful SCSI hard drive controller that magically loads data from Hard drive with around 0% CPU power.
My A3000 has 16MB of RAM which is a halfway barely usable amount. It really needs more RAM.
My A3000 can "easily" be upgraded to have PCI slots with a Mediator.
My A3000 can then be easily upgraded to a 32-bit GFX card with 256MB of RAM which would be a barely usable amount if someone would fix the flaw in P96 that prevents the usage of half of that RAM.
An A3000 with PCI slots and a 256MB gfx card + an Apollo Accellerator would make a very nice gfx card machine.
Are there any plans to make an A3000 Apollo?
I could simply put my A3000s in the closet and get an Apollo for my A1200! My A1200 already has the PCI slots! My A1200 has a completely trashed out garbage HD interface called IDE.
What is the projected price range of the A1200 Apollo?
-
I'd consider a move up from my A2000's current 14 MHz '020, but I can't see owning another AGA/ECS machine either (so no A600).
Now if they do a similar device for an A1200...
-
What is the predicted price for the Vampire?
The Vampire 600 is available for 90 €
-
The Vampire 600 is available for 90 %&$#?@!%&$#?@!%&$#?@!8364;
Only 90%&$#?@!%&$#?@!%&$#?@!8364; !!!!!
I see now that this is all just your evil plot to punish me for not buying an A600 when I had the chance. :D
-
BUG Report for Karlos:
The Euro symbol %&$#?@!%&$#?@!%&$#?@!8364; gets converted into %&$#?@!%&$#?@!%&$#?@!8364;
when editing a previously posted message.
-
Correction: The Euro symbol %&$#?@!%&$#?@!%&$#?@!8364; always gets converted into gibberish when posting a message. At least when copying and pasting the symbol in with Chrome.
-
Now if they do a similar device for an A1200...
Yep, that would undoubtedly be a better proposition than the A600 model, if for no other reason than there are a lot more A1200s out there.
I'd certainly grab an A1200 version.
Just curious - why is the Vampire only available for the A600 (and A500?)?
Cheers,
Mike.
-
.
Just curious - why is the Vampire only available for the A600 (and A500?)?
Cheers,
Mike.
because one needs to start somewhere?
-
Anyone have Vampire600 and Indivision ECS with P96 driver to show off?
-
Anyone have Vampire600 and Indivision ECS with P96 driver to show off?
Yep good idea, forgotten about that.
Or how about one of these?
[youtube]qmQhCKQJWjg[/youtube]
[youtube]MsT5BG3vloA[/youtube]
Or DOOM direct-chunky 256 color mode?
-
because one needs to start somewhere?
At the time the A600 user didn't have a lot of options whereas the A1200/3000/4000 users had quite a few cards to choose from.
Now the Vampire approach has been validated (high performance with low cost) then it makes sense to roll the same basic design out to all Amiga's.
-
Or Shapeshifter and MacOS8, would be a nice demonstration of CPU compatibility.
-
Someone already tried to run DigiBoosterPro 2.21, Prayer2, SongPlayer 1.53?
-
At the time the A600 user didn't have a lot of options whereas the A1200/3000/4000 users had quite a few cards to choose from.
Now the Vampire approach has been validated (high performance with low cost) then it makes sense to roll the same basic design out to all Amiga's.
they didnt even have released cards for a500/a2k yet, give them (and people around them) time. i am very willing to wait before the design will be ironed out to get to the next level. and if the core becomes available for third party projects a whole movement might break loose.
-
I have now read that Vampire600 is incompitible with Indivision ECS. Why?!
-
Also I read on EAB about Vampire600 V2, which is much much tinier, yet with bigger FPGA.
-
I have now read that Vampire600 is incompitible with Indivision ECS. Why?!
It is not, it's only the p96 driver that doesn't work.
-
given 020 compatibility i think it should work in the meantime?
-
Also I read on EAB about Vampire600 V2, which is much much tinier, yet with bigger FPGA.
The FPGA is bigger on the inside but smaller on the outside, it has more logic elements but is in a BGA package, the first version used a PQFP chip. Other than being a smaller board (about half the height) and a little more headroom in the FPGA it should be very similar to version 1, maybe with fewer headers.
-
A mild necro of this thread, but how is the project coming along?
-
A mild necro of this thread, but how is the project coming along?
Majsta, who developed the Vampire600, can be found here http://www.majsta.com/ where he posts updates occasionally.