Apollo Team announces the Vampire V4

[guest11527]

The quirks I'm referring to are about the differences in the cpu's themselves (68000, 68010, 68020, 68030, 68040, 68060)...compilers "hide" those things...sometimes...

Actually, the user space programming model is exactly identical *except* a single instruction, which is MOVE from SR which is priviledged in the 68010 and all above. Except that, user space is all the same.

The supervisor space programming model is, however, different, but that should be taken care of by the operating system. That is, however, not a quirk, but not much different from other CPU architectures.

Another laughable point is the demand for an MMU.  Yet another quirky feature.
https://en.wikipedia.org/wiki/Motorola_68851
https://en.wikipedia.org/wiki/Motorola_68451
Which MMU do you implement in the Apollo?

That is not quite the problem. It is not "which MMU", but rather "are the provided MMU features sufficient to provide the same features Motorola offered". Again, the MMU as a supervisor feature changed from generation to generation. That is not a problem. The problem is that the Apollo approach is much less powerful and much less flexible than *any* of the existing Motorola MMUs. A "page size" of 256K is certainly not sufficient.

To give you some idea, the PPC MMU is a completely different design, yet it is sufficiently complex to do anything a 68K MMU can do. The same does not hold for Apollo.

Yet people will whine about the *custom* one they are developing... /facepalm.

No, and if you reduce it to this, you don't understand the problem.

Again, OS-level support is missing in 3.1 for an MMU.

No, it's not. It has been there since a long time, in various tools.

How is that a must-have feature?

Because it allows many desirable functionalities for software development, as well as for end-user features.

When the OS has been elevated to a modern standard, then it will be *must-have* but the Apollo's MMU will set that standard going forward, not looking backwards.

Look, the "Os" cannot be "elevated" to a modern standard. That's simply because some of its core design decisions are inheritely broken, and in contradiction to what a "modern standard" would have to say.

[psxphill]

I don't consider patching in a jump-address to a subroutine/function an "emulation".

Those subroutine/function are emulating FPU instructions.

The name "FEMU" gives a good impression that it's emulation.

It's not just a one off either, x87emu predates it by decades https://github.com/bitblaze-fuzzball/fuzzball/tree/master/extras/x87-emu

[Louis Dias]

Actually, the user space programming model is exactly identical *except* a single instruction, which is MOVE from SR which is priviledged in the 68010 and all above. Except that, user space is all the same.

The supervisor space programming model is, however, different, but that should be taken care of by the operating system. That is, however, not a quirk, but not much different from other CPU architectures.



That is not quite the problem. It is not "which MMU", but rather "are the provided MMU features sufficient to provide the same features Motorola offered". Again, the MMU as a supervisor feature changed from generation to generation. That is not a problem. The problem is that the Apollo approach is much less powerful and much less flexible than *any* of the existing Motorola MMUs. A "page size" of 256K is certainly not sufficient.

To give you some idea, the PPC MMU is a completely different design, yet it is sufficiently complex to do anything a 68K MMU can do. The same does not hold for Apollo.


No, and if you reduce it to this, you don't understand the problem.


No, it's not. It has been there since a long time, in various tools.


Because it allows many desirable functionalities for software development, as well as for end-user features.


Look, the "Os" cannot be "elevated" to a modern standard. That's simply because some of its core design decisions are inheritely broken, and in contradiction to what a "modern standard" would have to say.

I think our perspectives are different.  If you look at the link for building compilers to handle the various cpus I linked to earlier, you'd see much more differences.
"user space" is nice.  Things need to happen a couple of levels below that to keep it nice.

My comment about elevating the OS was of course about creating a new modern 68K version.  But that proves the point of why an MMU will never be a must-have feature of OS3.X...  Virtual memory becomes a moot point when you can run on a couple of megs and suddenly now your hardware suddenly come equipped with .5GB to 4GB on-board...

[psxphill]

But that proves the point of why an MMU will never be a must-have feature of OS3.X...  Virtual memory becomes a moot point when you can run on a couple of megs and suddenly now your hardware suddenly come equipped with .5GB to 4GB on-board...

An MMU was never a must have feature for AmigaOS because there were very few Amigas that commodore shipped with an MMU.

However it's very much a nice to have feature. In my opinion you may as well make it 68040 or 68060 compatible because then you have software. But they have a religious disagreement with that.

Don't forget that OS3.X is not the only OS that runs on the Amiga. There are two unix versions that would be nice to run.

I would also love to see a sega mega drive emulator for amigaos that runs the game code natively and using an mmu to trap the hardware accesses. I don't know if real AGA would be quick enough, but SAGA should be.

[Niding]

An MMU was never a must have feature for AmigaOS because there were very few Amigas that commodore shipped with an MMU.

However it's very much a nice to have feature. In my opinion you may as well make it 68040 or 68060 compatible because then you have software. But they have a religious disagreement with that.

Don't forget that OS3.X is not the only OS that runs on the Amiga. There are two unix versions that would be nice to run.

I would also love to see a sega mega drive emulator for amigaos that runs the game code natively and using an mmu to trap the hardware accesses. I don't know if real AGA would be quick enough, but SAGA should be.

Its not a religious disagreement from what Ive seen Gunnar say on the matter.

There seems to be several considerations;

a) Time and manpower to do all the "to do items".

b) Gunnar/the team wants hardware that runs alot/most of the software available, BUT at the same time opens up for future developments on the software side. Making sure the FPU for example has functionalities beyond what was the norm in the 90s.

Ofcourse, some might say " well, thats not what defined Amiga back then, so stick to the legacy, dont create all this fluff that didnt exsist".
Jens will give you that option whenever he releases the A1200 Reloaded.

So Apollo gives you his option, and Jens his. Its up to you to decide which works best for your requirements/needs.

And is it unrealistic that the Apollo Core FPU will be able to deliver the legacy functionality? Be it thru its internals or thru library support?

There is the issue that in the future there might be programs released that works exclusivly on the Vampire, and I guess thats one of the main sources of annoyance/worry from some people.

[guest11527]

a) Time and manpower to do all the "to do items".

No, certainly, I agree. It's a massive project, and it's really astonishing how far they got. I certainly do not disagree with this.

b) Gunnar/the team wants hardware that runs alot/most of the software available, BUT at the same time opens up for future developments on the software side. Making sure the FPU for example has functionalities beyond what was the norm in the 90s.

Well... The disagreement is probably a bit what the "future" should be. For example, from a purely technical perspective, I understand that Gunnar wants to opt for a 64 (double precision) FPU only because it is readily available as an existing functional block on some FPGAs, but this also has the risk that it may potentially cause compatibility issues with existing software that may possibly depend on 96 bits. So it's a sacrifise to make. I personally disagree with this choice and I'd rather have a slower, but fully compatible FPU. That's basically because I believe that the times AmigaOs or Amiga would have had a "future" are long gone. Most people use it as a legacy system for "good times", but not as a productivity machine.

And is it unrealistic that the Apollo Core FPU will be able to deliver the legacy functionality? Be it thru its internals or thru library support?

It wouldn't be a hard problem to provide a mathieeedoubbas & friends that works with the new FPU, that's an easy problem to solve. However, this still doesn't make the FPU full 96 bit, and I am a bit afraid that *this* may *potentially* cause some problem here and there. But then again, a FPU is really rarely needed, and number crunching is not exactly the application domain of the Amiga - so one doesn't neither a *fast* FPU, nor a *precise* FPU. The current state as far as the FPU is concerned is therefore not as bad as some people want to make it appear.

There is the issue that in the future there might be programs released that works exclusivly on the Vampire, and I guess thats one of the main sources of annoyance/worry from some people.

Well, I don't even know whether this really worries me so much. Having a fully compatible working Amiga system would certainly be nice, given that the hardware aged. The problem is more that the Amiga environment depends a lot on its legacy software, and I don't believe that intentionally introducing an incompatibility "for the sake of speed" is a good move. I would put compatibility first, and speed second. After all, if I want speed without compatibility, I already have a PC, and the new core will still not be powerful enough for any real-world applications in first place, so why bother too much about speed in first place. Speed is nice, but compatibility is a "must have", and speed will come with new FPGA generations anyhow.

Unfortunately, this vision is not quite shared by the team, and that's probably the main issue. One could have done things "right" with a potentially slower full FPU, and a potentially slower full MMU, no matter about the details too much, but "complete enough" to do anything a 68K can (or could) do.

[Niding]

@Thomas

For those that deem the Amiga future completely dead, then having a future oriented FPGA shouldnt matter..or? They consider it competely dead right?
And for the record; I dont think Amiga will rise again either. I dont have illusions of conquest etc. But it can reach functionality level where you CAN actually use it for many/most day to day tasks.
Ofcourse, Ill gladly admit Ive grown more or less dependent on dual monitor for work. Then again, if you got a big/wide enough monitor, then that problem can be somewhat negated by adjusting the windows.

With regards to be able to run legacy programs; based on what ive seen, there seems to be decent compability as it stands already. Yes, you will always be able to find some program that crashes, but the same was the case when I upgraded from A500 to A1200.
And thats something that can be tweaked directly in the core if need be. OR library..? But its obvious that if a program is written badly enough, there is no reason to jump thru 20 hoops just to make it run. Gotta cut off at some point.

Then you got the issue of new programs requiring Vampire; if you are part of the Legacy only crowd, then new programs shouldnt matter to you anyhow. I realise you dont seem to worried about the direction the Apollo is heading. Quite neutral by the looks of it.

My take on it to sum it up; the situation for 68k has been stagnate, and many of us has been completely inactive hardware wise. Be it cause of failing accelerators, no working monitors, which can be negated by Indivision, but it got its issues.
With the Vampire; you have easy access to high performance (relativly speaking) RTG hardware, which makes the userexpirience very pleasant from a enduser perspective.
I have gotten the distinct sense that some developers are not so happy about the debugging enviroment for example.
But you have atleast gotten access to a certain portion of the community that enjoyed the Amiga thru youtube. We are all in our late 30s to 40++, many with disposable income.
As dead as the Amiga might be on a mainstream scale, there seems to be enough Vampires around to atleast accomodate SOME income for those intrested in crossdeveloping like Cherry Darling does for a wide range of platforms (Not Vampire at the moment tho).

I think you catch my drift on the topic :-)

[guest11527]

@Thomas

For those that deem the Amiga future completely dead, then having a future oriented FPGA shouldnt matter..or? They consider it competely dead right?

Not so. Look, we're talking about 25 year old hardware. New chips are not growing on the trees, nobody is manifacturing them anymore. More and more fake CPUs are on the market (or less and less authentic ones), legacy interfaces such as VGA (or even 15kHz output!) or the Amiga mice ports die out. Thus, if you want to preserve the system, some new hardware *has* to become available.

In my experience, emulators are not providing consistent emulation, and user experience is lacking. So yes, I believe that there is really a need for some form of new hardware - and what Jens is providing are at best new boards for old chips - so not really a solution for the problem.

And for the record; I dont think Amiga will rise again either. I dont have illusions of conquest etc. But it can reach functionality level where you CAN actually use it for many/most day to day tasks.

But that's only partially the problem of lacking hardware. It is a problem of lacking software. You do not exactly enable new products by breaking legacy either.

With regards to be able to run legacy programs; based on what ive seen, there seems to be decent compability as it stands already. Yes, you will always be able to find some program that crashes, but the same was the case when I upgraded from A500 to A1200.

Yes, certainly, but the situation was a bit different back then. Back then, one could hope that sofware vendors would have some interest in fixing up their broken software to reach new customers, but that's no longer given. Nobody will fix old code at this point anymore.

And thats something that can be tweaked directly in the core if need be. OR library..? But its obvious that if a program is written badly enough, there is no reason to jump thru 20 hoops just to make it run. Gotta cut off at some point.

I would prefer to keep this to an absolute minimum, and I would pick priorities someway different, as said.

[psxphill]

Its not a religious disagreement from what Ive seen Gunnar say on the matter.

There seems to be several considerations;

a) Time and manpower to do all the "to do items".

b) Gunnar/the team wants hardware that runs alot/most of the software available, BUT at the same time opens up for future developments on the software side. Making sure the FPU for example has functionalities beyond what was the norm in the 90s.

Exactly. He has always had a hatred for the FPU and MMU compatibility and the fan boys think he's the second coming because he added some opcodes that accelerate some software that doesn't exist yet.

The worst thing you can ever do is have someone with a strong opinion about things and a bunch of enablers.

[Niding]

Eeeeh, you psxphill is the one assigning strong feelings in this disscussion.
So if I enjoy using generic monitors with no hassle, with high color and resolution with no system lag, Im a mindless fanboy?

I doubt very much Gunnar hates fpu or mmu in the old form, he just got other plans going forward.
One can have objections about the choice, like Thomas has, without assigning  crusaderlike motives behind it.

I prefer Android over IOS, but I accept IOS got its merits, and is prefered by the majority of people I know.
Im not feeling the urge to call them fanboys or enablers.

Its a cheap argument tool to stereotype and categorize people that way.

[psxphill]

Eeeeh, you psxphill is the one assigning strong feelings in this disscussion.

I'm just pointing it out. Whether you choose to ignore the signs is up to you. It killed natami.

Gunnar is on a crusade to get apollo in embedded designs. The Amiga is a test bed and advertising, so fpu/mmu compatibility isn't that important for him. I know I'm not the only one who understands that. Go talk to matthey and kolla.

I have no idea what your point is about monitors, it doesn't seem to relate to anything I said.

[Crom00]

I don't think Gunnar hates FPU's. He has stated that purchase a Vampire only if you feel it has the features you need today. Keep in mind UNLIKE other product ranges the features can be upgraded and improved via flashing the core of your choice.

V4 has enough space for an FPU. I wouldn't be a stretch to envision the work done on FEMU put into an FPGA.

The I supposed folks will  then complain the V4 doesn't have a floppy drive controller for floppy compatibility...and that's fine... SO Alright then... it has I/O ports, perhaps someone can fab a floppy port. I dunno beats the hell out of recapping Amigas every 15 years.

[Louis Dias]

I don't think Gunnar hates FPU's. He has stated that purchase a Vampire only if you feel it has the features you need today. Keep in mind UNLIKE other product ranges the features can be upgraded and improved via flashing the core of your choice.

V4 has enough space for an FPU. I wouldn't be a stretch to envision the work done on FEMU put into an FPGA.

The I supposed folks will  then complain the V4 doesn't have a floppy drive controller for floppy compatibility...and that's fine... SO Alright then... it has I/O ports, perhaps someone can fab a floppy port. I dunno beats the hell out of recapping Amigas every 15 years.

They will always find something to complain about.
In fact I want to go on record now complaining because the kitchen sink is missing!

[Niding]

I'm just pointing it out. Whether you choose to ignore the signs is up to you. It killed natami.

Gunnar is on a crusade to get apollo in embedded designs. The Amiga is a test bed and advertising, so fpu/mmu compatibility isn't that important for him. I know I'm not the only one who understands that.

I have no idea what your point is about monitors, it doesn't seem to relate to anything I said.

The comment about monitors was just a generic comment about userfriendliness using the Vampire hardware. Virtually plug and play after installing a few programs.
As much as I enjoyed Indivision on my A1200, it doesnt compare for me personally.
I realise a pimped up A4000 with 060, graphicscard etc will perform amazingly, but thats scarse hardware at premium price. The Vampire provide that in one small card at relativly low price. Without configuration hassle.

Could you expand on what you mean about Gunnars plans regarding Apollo in embedded designs?

[guest11527]

I don't think Gunnar hates FPU's. He has stated that purchase a Vampire only if you feel it has the features you need today.

While I have certainly no problem if it provides features you need today, I have problems if it does not provide the features I needed yesterday - since that is what the whole problem is really about.

The I supposed folks will  then complain the V4 doesn't have a floppy drive controller for floppy compatibility...and that's fine... SO Alright then... it has I/O ports, perhaps someone can fab a floppy port. I dunno beats the hell out of recapping Amigas every 15 years.

I'm really much less concerned about exact reproduction of the hardware. Floppies, Amiga mice, VGA... that's all outdated anyhow, and they are failing and not available as new stock. However, if the FPGA fails to run all my software properly, then that somehow conflicts to - at least my - requirements.

[Niding]

@Thomas

Thats a fair attitude to have.

Computers are ultimatly just a tool, and if it cant do what you want/need it to do, then its reasonable to opt out. Thats a objective evaluation noone can fault you for.

Im not going lie, I obviously would want as many as possible to utilize this relativly high performance hardware which brings 100s or 1000+ people up to the specs that only very few had back in the days.
Ofcourse, me only using computers for officework, music and some simple graphics to go with the presentations I make for work; I dont face the same headache as developers like yourself might face. Im not blind to that disparity in userfriendliness based on your workflow and goals.